-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2-freeze creates freeze file with non-single-point version ranges. #6110
Comments
Fwiw, the current pragmatic |
Won't generating something like
be already more precise? |
sure, that'd be an incremental improvement within the current inadequate constraint-language; but I was trying to point out that we have a far bigger problem at hand... you'd just be improving the current stop-gap solution ;-) |
Nothing wrong with making the stop-gap solution better. |
More than one version of the same package appears in the freeze file when you pick a separate version for a Cabal freeze should not use |
Describe the bug
After
v2-freeze
I see things likein
cabal.project.freeze
.To Reproduce
I'm able to reproduce this with a current
master
ofpostgresql-simple
commitd0fcf2800b184f095c4aac56db4a8a3ed1a8a829
I think that any package with custom-setup packages in dependencies, and suitable situation (see below) can trigger this:
Expected behavior
I'd expect only
thisVersion
, i.e.== x.y.z.w.
version ranges to exist incabal.project.freeze
.Technically, I'd expect that not being possible at all (i.e. freeze file representation would use
Version
, notVersionRange
, and if independent goals require it, then use proper goal qualification, ifany
would be||
-ed range)System informataion
Additional context
The problem is because independent goals are merged together, see
Cabal
dependencies in custom-setup are merged with "main" stuff. Which makes freeze file more like "gelly".The text was updated successfully, but these errors were encountered: