Closed hvr closed 7 years ago
Thanks for this PR. I've merged it in.
However, I'm having trouble uploading the package when using pvp-bounds: both
. When I run stack upload
, I get the following error:
$ stack upload .
Getting file list for /home/me/git/pretty-simple/
Building sdist tarball for /home/me/git/pretty-simple/
Unable to parse cabal file /tmp/stack13425/pretty-simple-1.0.0.4/pretty-simple.cabal: FromString "'then' branch of 'if' is empty" (Just 55)
It looks like it is failing on the if / else
that I'm using to determine whether or not to build the example program.
So I wasn't able to actually upload a version to Hackage yet that uses pvp-bounds: both
.
Actually I had one more question about pvp-bounds: both
. I've never used the pvp-bounds
config option before, so let me know if this question doesn't make sense.
Doesn't it make the version bounds too restrictive on Hackage? In Travis CI, I'm testing against Stackage LTS 5 (GHC 7.10.3), LTS 6 (GHC 7.10.3), LTS 7 (GHC 8.0.1), and nightly (GHC 8.0.1). So, for instance, the lower version bound for the lens
dependency would be the version in LTS 5 (which is lens-4.13), and the upper bound for the lens
dependency would be the version in nightly (which is lens-4.15
).
However, pvp-bounds: both
would give the package bounds like lens >= 4.14 && < 4.15
(since the stack.yaml
file is pointing to LTS 7 which is lens-4.14).
Does this not cause a problem for users of cabal
?
@cdepillabout as to the stack upload
error, you should file an issue @ https://github.com/commercialhaskell/stack/issues
And you're right: if you test against multiple stackage snapshots then we'd actually need a variant of thepvp-bound
-feature that allows to generate a union of version ranges inferred from multiple stackage snapshots. Iirc there's an issue about that in Stack's issue tracker, and I've also seen an external tool being worked on that may help with that as well... so in your case pvp-bounds:both
may not be optimal yet.
@hvr I will file an issue on stack's issue tracker.
It looks like https://github.com/commercialhaskell/stack/issues/2262 is the issue about pvp-bounds
.
So, if I don't use the pvp-bounds
feature, do you have a suggestion on what I should do to make it easier for cabal users? Just manually specify version bounds?
Also, in your original error, it looks like you're trying to use pretty-simple
with GHC 7.8? Do you need pretty-simple
to support older versions of GHC?
pretty-simple
is currently only supporting GHC 7.10+, but that decision is pretty arbitrary. I just didn't want to deal with CPP'ing around Control.Applicative
while doing development. But now that pretty-simple
is working well, I have no problem with supporting older GHC versions.
@cdepillabout It's totally fine to support only GHC 7.10 or later, especially if this avoids CPP. I noticed this issue because the Hackage matrix CI builder stumbled over it. :-)
Oh, okay, I see. I guess the Hackage matrix CI builder just needs the base
version bounds specified correctly?
This avoids cabal running into the compile failure below: