cabal ignores the 'cabal-version' field when solving for setup dependencies

[grayjay]

This can cause the build to fail when the setup-depends range for Cabal is less restrictive than the cabal-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 reflect cabal-version before dependency solving.

[23Skidoo]

This can cause the build to fail when the setup-depends range for Cabal is less restrictive than the cabal-version for a given package.

Can't we just make this an error in D.PD.Check?

[grayjay]

Yeah, that would also work. Is it okay if existing packages fail the check?

[23Skidoo]

I think that we already have some (obsolete) packages on Hackage that fail cabal check.

[ezyang]

@grayjay Are you planning to fix this bug? If so assign yourself and milestone this to 2.0 ;)

[grayjay]

I wasn't planning on fixing this soon.

[ezyang]

OK, I milestoned this appropriately.

[grayjay]

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 cabal-doctest.