Version constraints and cabal.config files

Miëtek Bak mietek at bak.io
Wed Mar 25 12:26:50 UTC 2015


On 2015-03-25, at 12:16, Michael Snoyman <michael at fpcomplete.com> wrote:

> Trying to understand the problem: currently, with your approach, if the project depends on a library not in the LTS Haskell release, then the cabal-install dependency solver won't be able to find it. Instead, you'd like to be able to use the dependency solver to track down those extra dependencies. Is that correct?
> 
> If so, why not take a multi-pass approach: download the cabal.config from stackage.org (which creates an inclusive snapshot), and then use --dry-run, which will tell you all the packages to be used.

You’re correct.  However, this will have to be `cabal install --dependencies-only --dry-run`, and not `cabal freeze --dry-run`, because `cabal freeze` always completely ignores any existing version constraints, whether local or global (https://github.com/haskell/cabal/issues/2265).

I’m planning to switch away from `cabal freeze` soon, but it’s not going to be a drop-in replacement (https://github.com/mietek/halcyon/issues/52).

This is a good moment to carefully consider the meaning of a per-application `cabal.config` file, and whether the `cabal freeze` flavour should be completely replaced by separate constraints files.  Perhaps, as mentioned in the original `cabal freeze` proposal, we could also have separate constraints sets for different GHC versions.

I’m hoping Cabal developers could chime in on the discussion.


-- 
Miëtek
https://mietek.io


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150325/b580232f/attachment.bin>


More information about the cabal-devel mailing list