[Haskell-cafe] Version constraints and cabal.config files

Anthony Cowley acowley at gmail.com
Wed Mar 25 14:21:05 UTC 2015


The suggestion to use "cabal install --dependencies-only ..." instead
of "cabal freeze" in that issue is really nicely presented. "cabal
freeze" is close to the right thing, but it's just not as fully
featured as "cabal install" (e.g. taking flags).

As for Stackage, I think it would be helpful to cache the full build
plans computed for each package in Stackage. This is most of the work
my Nix tooling currently does, so it would be a big time saver.

Anthony (re-sending after joining the GitHub group)

On Wed, Mar 25, 2015 at 8:26 AM, Miëtek Bak <mietek at bak.io> wrote:
> 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
>
>


More information about the Haskell-Cafe mailing list