Cabal: Cabal check accepts new bounds for old versions

[tfausak]

Running cabal check against a package description that uses ^>= bounds with cabal-version: >= 1.10 doesn't report any problems. It should complain that ^>= require cabal-version: 2.

Discovered in https://github.com/sol/hpack/issues/213.

[23Skidoo]

There's a check for that in D.PackageDescription.Check. Indeed, in my testing I get:

$ cabal check
[...]
* The package uses major bounded version syntax in the 'build-depends' field:
base ^>=4.10. To use this new syntax the package need to specify at least
'cabal-version: >= 2.0'. Alternatively, if broader compatibility is important
then use: base >=4.10 && <4.11
[...]

Which version of cabal-install are you using? Can you please show us the .cabal file you're using for testing?

[tfausak]

Huh, weird. I'm using Stack 1.6.1 and Cabal 2.0.1.1/cabal-install-2.0.0.1. I thought stack sdist ended up calling cabal check, but maybe it does something else. Sorry for the noise!

[23Skidoo]

For the record, I get the same result with both cabal-install 2.0.0.1 and HEAD.

[tfausak]

Also for the record, stack upload does more checks than stack sdist. But it's not clear if either of them actually do the same thing as cabal check. https://github.com/commercialhaskell/stack/issues/2501

[23Skidoo]

I'd recommend filing a bug report for Stack then.

[mgsloan]

The sdist command does run the checks - https://github.com/commercialhaskell/stack/blob/master/src/main/Main.hs#L755 . Here's where the checks in the Cabal library get run - https://github.com/commercialhaskell/stack/blob/master/src/Stack/SDist.hs#L410

[snoyberg]

Thanks for the feedback @23Skidoo, someone pinged me about this and I was curious. I've written a PR to fix this in Stack if you're curious as well:

https://github.com/commercialhaskell/stack/pull/3640/files

It appears that the Cabal check code is paying attention specifically to the buildDepends field of the PackageDescription, which the Stack code base doesn't populate as it's never used internally. I'm surprised that it's not checking the GenericPackageDescription itself for the bounds operators to be used, but this workaround is simple enough on the Stack side, and likely makes it much closer to what cabal-install itself is doing.

[23Skidoo]

Probably because the check was easier to write that way (the field contains all the build-depends of all components at the time the check runs). However, the plan is to get rid of that field at some point, see #2066.

[snoyberg]

That looks great, and explanation makes sense. Thanks!

On Tue, Dec 12, 2017 at 11:04 AM, Mikhail Glushenkov <
[email protected]> wrote:

Probably because the check was easier to write that way (the field
contains all the build-depends of all components at the time the check
runs). However, the plan is to eventually get rid of that field at some
point, see #2066 https://github.com/haskell/cabal/issues/2066.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/haskell/cabal/issues/4951#issuecomment-350988362, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADBB06o4k7t2SLFeJI8EFOWD8RqoUFUks5s_kGSgaJpZM4Q-Ndq
.