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

stack-1.6.1 does not compile in Nightly #3126

Closed
peti opened this issue Dec 19, 2017 · 11 comments

Comments

@peti
Copy link
Contributor

commented Dec 19, 2017

http://hackage.haskell.org/package/stack-1.6.1 from Stackage Nightly 2017-12-19 wants hpack >=0.20.0 && <0.21, but the same package set has http://hackage.haskell.org/package/hpack-0.21.2.

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2017

You're looking at the wrong revision of the stack.cabal file. Stackage snapshots specify exact cabal file revisions via a SHA256 of their contents.

@peti

This comment has been minimized.

Copy link
Contributor Author

commented Dec 19, 2017

I am using https://www.stackage.org/lts-10.0/cabal.config et al to configure my build with cabal-install. It's not obvious to me how to choose a "correct" revision in that case. It's also not clear to me why the old revision appears to be correct, but the newer one apparently is wrong. Isn't that somewhat unusual?

@DanBurton

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2017

@snoyberg @borsboom: to address this particular issue, what do you think about revising stack 1.6.1 again to relax the upper bound on hpack to < 0.22?

@DanBurton

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2017

@peti to use this cabal.config with cabal, you could try --allow-newer=hpack. Perhaps there's a way to encode this sort of thing in the cabal.config itself.

It's also not clear to me why the old revision appears to be correct, but the newer one apparently is wrong. Isn't that somewhat unusual?

Yes. The original revision was uploaded with no constraints, and the second revision added all constraints. I forget exactly what that was for; this trickery had something to do with getting stack back into nightly builds.

@borsboom

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2017

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2017

There is no way to use the cabal.config file to perform the builds, see fpco/stackage-server#232. cabal-install simply lacks the features necessary to make this happen. I'd be in favor of completely removing the availability of the cabal.config files from stackage.org to avoid this kind of confusion.

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2017

I've added a warning about the lack of support for revisions in cabal.config in fpco/stackage-server@f9632d7.

@fgaz

This comment has been minimized.

Copy link

commented Dec 20, 2017

I'd be in favor of completely removing the availability of the cabal.config files from stackage.org to avoid this kind of confusion.

Please consider leaving it as it is, as it may be useful to some (well, me for example) and the warning you just added removes the confusion

@snoyberg

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2017

@fgaz No need to worry, I'll be leaving the files there for now.

Since this is not a bug in Stackage, closing.

@snoyberg snoyberg closed this Dec 21, 2017

@peti

This comment has been minimized.

Copy link
Contributor Author

commented Dec 21, 2017

@DanBurton,

The original revision was uploaded with no constraints, and the second revision added all constraints. I forget exactly what that was for; this trickery had something to do with getting stack back into nightly builds.

I still don't understand why the OLD revision is supposed to be the correct one whereas the NEW revision is apparently wrong. This makes no sense to me. Why doesn't stack have exactly those constraints that are actually valid for the tool? Why do I have to bother working around constraints that are apparently not for real?

@borsboom

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2017

From a PVP point of view, the revision 0 is not correct at all. cabal-install will not be able to come up with a working build plan based on the (lack of) constraints in that revision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.