-
Notifications
You must be signed in to change notification settings - Fork 697
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
cabal ignores the 'cabal-version' field when solving for setup dependencies #3751
Comments
Can't we just make this an error in |
Yeah, that would also work. Is it okay if existing packages fail the check? |
I think that we already have some (obsolete) packages on Hackage that fail |
@grayjay Are you planning to fix this bug? If so assign yourself and milestone this to 2.0 ;) |
I wasn't planning on fixing this soon. |
OK, I milestoned this appropriately. |
It might be better to add an implicit constraint, as in #5184, because that would also work when there is no direct dependency on Cabal. For example, a setup script could only declare a dependency on |
Here is a recent case of this in the wild:
So, @grayjay wrote:
I also think that an implicit constraint is in order; everything else is counterintuitive. |
This can cause the build to fail when the
setup-depends
range for Cabal is less restrictive than thecabal-version
for a given package. See #3723 (comment).The current behavior is technically correct, because it is possible for a setup script to depend on one version of Cabal and implement the command interface from a different version. I think it would be better to prevent build failures in the more common case, though.
One solution is to update the
setup-depends
constraint on Cabal to reflectcabal-version
before dependency solving.The text was updated successfully, but these errors were encountered: