{"push_id":1038601398,"size":10,"distinct_size":10,"ref":"refs/heads/master","head":"aa4d30d7b8bb270b57ec383e8d0b3123dec67add","before":"692d8bf41a37ba29b704695b78d15f0aa8c72f74","commits":[{"sha":"352f5795745a95d1d1dcaa941ee5507a78404016","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"Add new style project planning\n\nThis implements the planning phase of the new nix-style package build and\ninstall system. In particular it includes the calculation of the\nnix-style package ids by hashing all the package configuration.\n\nProject planning is separated from project building.\n\nThe planning phase starts with finding the packages in the project and\nthen solving. We solve without looking at the installed packages in the\nstore. This makes everything more deterministic. The only installed\npackages the solver looks at are the globally installed ones. This\napproach also means we don't have any need of solver options like\n--reinstall or --avoid-reinstalls etc.\n\nThe bulk of the planning phase is elaboration. We take the project\nconfiguration and the solver's InstallPlan and elaborate the latter into\nan ElaboratedInstallPlan. This is intended to contain all the details\nneeded for the build phase. For example all the \"setup\" command flags\nare calculated directly from the elaborated plan.\n\nThe building phase is then intended to be much simpler and free of much\nlogic or policy. All of the complicated logic and policy is supposed to\nbe in the planning phase. This should also make things a lot easier to\ndebug, we can look at the plan we calculate and see if we're producing\nthe right build instructions, rather than debugging based on the actions\nwe end up executing.\n\nDoing all the planning up front is also crucial to calculating nix-style\npackage hashes. This means we have the package ids up front. This then\nallows us to have another up-front phase where we improve the plan by\nreplacing source packages with installed packages from the store.\n\nAll of this stuff is done in the Rebuild monad, with a few levels of\ncaches, so most of the time we can avoid recomputing the plan. In\nparticular we want to avoid re-running the solver unless we have to.\n\nThere are still quite a number of TODOs, which are categorised.\n\n(cherry picked from commit 2d065c8cc8c430ea579ecd23662f4e58ad5d1f3c)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/352f5795745a95d1d1dcaa941ee5507a78404016"},{"sha":"9d91e201f12631d7a91f4c895d60269c41d4fe54","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"Split out reusable lookupReadyPackage util in InstallPlan\n\nUsed in the next patch.\n\n(cherry picked from commit 150c3189724bb8150741e0ca22617d8b2f7208d2)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/9d91e201f12631d7a91f4c895d60269c41d4fe54"},{"sha":"3e13931e59d29f22fa69b5fcc09ea8fee6d7ca67","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"InstallPlan util to replace a ready package with an installed one\n\nThere are two cases in which we replace source packages with ones that\nare already installed: during planning when we improve the plan by\nreplacing configured source packages with pre-existing packages from the\nstore, but also there's just the case of skipping over a local package\nthat is already built and up to date. In the latter case we're replacing\na package in the Configured state not with one in the PreExisting state,\nbut with one in the Installed state, as if it had been built and\ninstalled (which in a sense of course it has).\n\nThis new util is for the latter case.\n\n(cherry picked from commit e869d80362d80ab1f30a72d29882192edb219899)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/3e13931e59d29f22fa69b5fcc09ea8fee6d7ca67"},{"sha":"a65264035338bce6226931f42f63e9d45db18ece","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"Add new style project building\n\nThis stage takes the ElaboratedInstallPlan and executes it. It does it\nin two passes.\n\nThe first pass is the \"dry run\" pass where we work out which packages\nand components within packages we actually need to build. If we are in\nfact in --dry-run mode then of course this is the only pass we run, we\nhave enough info after this to accurately report on what we would do.\n\nThe first pass does the file monitor change stuff, which checks if\npackage config has changed and probes for package file changes. Based on\nthis we make a note of which phase of the build we would start at, up to\nand including skipping building that package entirely. In the latter\ncase we replace the Configured package by a corresponding Installed\npackage.\n\nThe first pass also prunes the ElaboratedInstallPlan based on the\ntargets that the user actually wants to build. For example we solve and\nplan on the basis that the user might want to run the test suites or\nbenchmarks, but that doesn't mean we want to build them all the time\n(they'll usually pull in additional deps). So there's a moderately\ncomplex pass where we keep just the packages and components that are\nneeded to build the target components.\n\nThe first pass is moderately complicated but it makes no state changes\nand just returns the updated ElaboratedInstallPlan, so it should make\nthings easier to debug.\n\nThe second phase has very little logic it just does what its told based\non all the earlier passes. For each package the dry run pass has worked\nout which build step to start with, e.g. downloading, configuring or\nbuilding.\n\nThe major cases the build phase has to deal with are packages that will\nbe built and installed to the store, vs packages that are local and so\nare built inplace. It is only the latter that need all the complex\nrebuild checking. In both cases all the \"setup $cmd\" flags are\ncalculated by the planning phase and we just do as we're told.\n\n(cherry picked from commit 300d9bad9f5154ed01f09d1375758fd1d0b65907)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/a65264035338bce6226931f42f63e9d45db18ece"},{"sha":"2d569609e1a92ace6512e347d2856b35bd2ab7c2","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"Extend file globs and file glob monitors\n\nFile globs can now be absolute, e.g. starting with / or c:\\\nAlso allow homedir relative, ie ~/\n\nGlobs can also have a trailing slash, in which case they only match\ndirectories, not files.\n\nPreviously whether globs could match dirs was not totally consistent.\nThe matchFileGlob would match dirs, but the file monitor globs would\nnot. The file monitor globs can now match dirs (or with a trailing\nslash, only match dirs). File monitors now also detect changes in the\nfile type, ie switching from file to dir or the other way around.\n\nThe file monitor are now pretty consistent between single file monitors\nand globs monitors. They now have equivalent capabilities and share\ncode. For a single file or for a glob we can now control what we\nmonitor if the path is a file or a dir. In both cases we can monitor\nmere existence, non-existence or modification time. For files we can\nadditionally monitor content hash.\n\nFile monitors now also detect changes in the file type, ie switching\nfrom file to dir or the other way around.\n\nNew tests cover all these new file monitor cases. There are also new\ntests for glob syntax, covering printing/parsing round trips.\n\n(cherry picked from commit f6c1e71c591c3eb53af15c7dfd0ffcb2a21a93d7)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/2d569609e1a92ace6512e347d2856b35bd2ab7c2"},{"sha":"a4e54a68cb858529ec37822516fa1728cc375696","author":{"email":"f69bf5514fde50d7fb64e12e8052d5aebfc37e06@community.haskell.org","name":"Duncan Coutts"},"message":"Quote package locations with spaces when printing\n\nAnd extend the project config print/parse tests to cover quoted strings.\n\n(cherry picked from commit 72b93d91beb7d3e020bc572a171356fbbe0dc4bf)","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/a4e54a68cb858529ec37822516fa1728cc375696"},{"sha":"5c8c1c7c9bfc20e1a78e444a3c5d8e419efdd134","author":{"email":"5c53b53d2a94579426b41a2f5a7fae3851d636a3@gmail.com","name":"Mikhail Glushenkov"},"message":"Update 'bootstrap.sh'.","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/5c8c1c7c9bfc20e1a78e444a3c5d8e419efdd134"},{"sha":"2d68db1191ad2ba02bc7c3c3b6fbff2a4d5080dd","author":{"email":"5c53b53d2a94579426b41a2f5a7fae3851d636a3@gmail.com","name":"Mikhail Glushenkov"},"message":"Whitespace.","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/2d68db1191ad2ba02bc7c3c3b6fbff2a4d5080dd"},{"sha":"ebb6c5524ef5039b6255e99aac848577ea4e04c1","author":{"email":"5c53b53d2a94579426b41a2f5a7fae3851d636a3@gmail.com","name":"Mikhail Glushenkov"},"message":"80-col violations.","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/ebb6c5524ef5039b6255e99aac848577ea4e04c1"},{"sha":"aa4d30d7b8bb270b57ec383e8d0b3123dec67add","author":{"email":"5c53b53d2a94579426b41a2f5a7fae3851d636a3@gmail.com","name":"Mikhail Glushenkov"},"message":"Merge pull request #3244 from 23Skidoo/merge-1.24\n\nMerge nix-local-build changes from 1.24","distinct":true,"url":"https://api.github.com/repos/ghc/packages-Cabal/commits/aa4d30d7b8bb270b57ec383e8d0b3123dec67add"}]}