On 2015-03-25, at 09:59, Chris Done
Halcyon wants a constraints file for a particular app to list all Cabal packages which are the app’s direct or indirect dependencies.
Why is that? What does it do with the cabal.config file?
There are two flavours of `cabal.config` files: (1) `cabal freeze`-flavoured, declaring a complete set of dependencies for a particular application, and (2) the Stackage flavour, declaring a set of packages which are guaranteed to build together. It’s worth noting that the first flavour was originally proposed to be a separate file with a simpler syntax, named `cabal.freeze` (https://github.com/haskell/cabal/issues/1502). Unfortunately, this didn’t make it into cabal-install, due to lack of time (https://github.com/haskell/cabal/pull/1519). Halcyon supports `cabal freeze`-flavoured `cabal.config` files, and also accepts separate constraints files, named `.halcyon/constraints`. The declared version constraints are used to calculate a sandbox hash. When building an application, Halcyon uses the sandbox hash to try and locate a previously-built sandbox archive. If available in local cache or remote storage, this archive is restored, completely side-stepping the need to `cabal install --dependencies-only`. Otherwise, a new sandbox is built, archived, and uploaded to remote storage. Moreover, if a full match for the sandbox hash isn’t located, Halcyon attempts to locate a partial match. Each previously-built sandbox is assigned a score, which reflects the number of required dependencies contained within. Sandboxes with extraneous dependencies are rejected. The highest-scoring partial match is used as a base for building the new sandbox. While inferior to the package-level granularity provided by Nix and proposed for future versions of Cabal, the approach implemented in Halcyon has the benefit of working with regular Cabal packages and repositories, and being used in production since June 2014. -- Miëtek https://mietek.io