Skip to content
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

Cassava-0.5.1.0 not in nightly #2842

Closed
phadej opened this issue Sep 7, 2017 · 5 comments
Closed

Cassava-0.5.1.0 not in nightly #2842

phadej opened this issue Sep 7, 2017 · 5 comments

Comments

@phadej
Copy link
Contributor

phadej commented Sep 7, 2017

... and there doesn't seem to be open issue about it?

@snoyberg
Copy link
Contributor

snoyberg commented Sep 7, 2017

The build constraints file includes a link to the relevant issue in the Stackage upper bounds section:

commercialhaskell/stack#3345

@phadej
Copy link
Contributor Author

phadej commented Sep 7, 2017

So cassava-0.5.1.0 will be holded, until there is a release of stack which can handle that flag name?

@snoyberg
Copy link
Contributor

snoyberg commented Sep 7, 2017

Or until the maintainer decides he's willing to modify the flag name as was requested in that issue. Either one will work.

@hvr
Copy link

hvr commented Sep 7, 2017

The key insight in commercialhaskell/stack#3345 (comment) still holds.

And for the record, I never asked for packages I maintain to be included in Stackage, and I specifically tell everyone who suggests to add packages to Stackage that I don't mind to have them included, as long as it doesn't cause me to do anything I wouldn't have done anyway; I consider Stackage to be merely just another one of several existing downstream distributions of Haskell packages, no more and no less. If you don't agree, feel free to drop all my packages, I really don't care; being part of Stackage or not has no relevance to me.

@decentral1se
Copy link
Member

Once something gets decided for Casava, please someone submit the PR and we'll go from there.

Thanks.

tfausak added a commit to tfausak/cassava that referenced this issue Sep 8, 2017
This flag name was changed without comment in 6e1ff78. It has caused a few problems:

- commercialhaskell/stack#3345
- commercialhaskell/stackage#2755
- commercialhaskell/stackage#2759
- commercialhaskell/stackage#2842
- haskell/cabal#4686
- haskell-hvr#150

Those problems either caused or accelerated some (attempted) changes in Cabal:

- haskell/cabal#4654
- haskell/cabal#4687
- haskell/cabal#4696

Those problems also caused a change in Stack:

- commercialhaskell/stack#3349

In short: Cabal never had any trouble with this. Stack did. The current master version of Stack can handle flags like this, but no released versions of it can. It's not clear when the next version of Stack will be released. In the meantime, no Stack users can use this package. This commit changes the offending flag to something that Stack can handle. By using a flag that Stack can handle, Stack users can once again use this package, and it can return to Stackage. There are no apparent downsides to using a more compatible flag name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants