'freeze' ignores existing constraints #2265

mietek opened this Issue Dec 10, 2014 · 5 comments


None yet

5 participants

mietek commented Dec 10, 2014

As mentioned in #1519 (comment):

I mostly like the idea of refreezing by rerunning cabal freeze and having it ignore [cabal.config]. But freezing something that is already frozen and having it change seems surprising.

It appears that as currently implemented, cabal freeze ignores any constraints set both in the local cabal.config file, and in the global ~/.cabal/config file. Re-running cabal freeze with no packages installed results in a new set of constraints, matching the newest available versions of all dependencies.

cabal freeze also does not support the --constraint= command-line option, available for cabal install.

In order to improve the workflow for upgrading dependencies, I wanted to add two options to Halcyon, --ignore-constraints and --ignore-all-constraints, corresponding to the --ignore-frozen and --ignore-all-frozen options proposed in #1519 (comment). Unfortunately, with no apparent way to specify constraints for cabal freeze, I can only support --ignore-all-constraints.

Additionally, there is no way to help users who have included partial cabal.config files with their applications. If cabal freeze did not ignore constraints, this could be detected and the user could be warned.


@mietek on #1519 you asked me to confirm if cabal freeze ignores the constraints in cabal.config. It does.

If I recall correctly that was the majority opinion of what the correct / initial implementation should be. I'd also like to see cabal freeze pay attention to the constraints and gain some options to ignore all or selected constraints.


The --constraint= option for cabal freeze seems like a good idea too. Though I've not personally had any use for that.

@23Skidoo, @tibbe would changing the default behaviour for cabal freeze to stop ignore the constraints in cabal.config, and adding --ignore-constraints and --ignore-all-constraints options be acceptable to you?

mietek commented Dec 10, 2014

@benarmston: Thanks for the quick reply. Indeed, I read your proposed use cases carefully, and I am in favour of the design.

mietek commented Dec 12, 2014

Halcyon supports ignoring all existing constraints with the HALCYON_IGNORE_ALL_CONSTRAINTS option, as this does not require modifications to cabal-install.

@mietek mietek referenced this issue in mietek/haskell-on-heroku Dec 12, 2014

Improve cabal.config handling #22

mietek commented Dec 18, 2014

@hvr @xich Having a --constraint= option for cabal freeze could also help work around the problem of old package versions not declaring version constraints upper bounds.

For example, because Scotty did not declare upper bounds for scotty-0.5.0, and has not released a version supporting monad-control-1.0.* yet, current install plans will ignore the newest available scotty-0.9.0, and select scotty-0.5.0, which no longer compiles successfully.

[_82] next goal: scotty (dependency of digitalocean-button-1.0)
[_82] rejecting: scotty-0.9.0, 0.8.2, 0.8.1 (conflict: monad-control==,
scotty => monad-control>= && <0.4)
[_82] rejecting: scotty-0.8.0, 0.7.3 (conflict: text==, scotty =>
text>= && <1.2)
[_82] rejecting: scotty-0.7.2, 0.7.1, 0.7.0, 0.6.2, 0.6.1, 0.6.0 (conflict:
case-insensitive==, scotty => case-insensitive>= && <1.2)
[_82] trying: scotty-0.5.0

As freeze is the simplest way to ask Cabal “what do you need installed for this particular package” without installing anything, being able to say freeze --constraint=scotty-0.9.0 would be a big help here.

(I believe constraints of the form scotty-0.9.0 should be accepted as equivalent to scotty ==0.9.0.)

@ttuegel ttuegel added this to the cabal-install-1.24 milestone Apr 24, 2015
@ezyang ezyang modified the milestone: cabal-install 2.0 Sep 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment