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