stack-1.6.1 does not compile in Nightly

[peti]

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]

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]

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]

@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]

@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]

Briefly since on my phone: we're using the stackage no-revisions feature to avoid needing to spend a lot of time updating bounds for stackage, but so that cabal-install can also come up with a working build plan for the convenience of those who must bootstrap Stack that way. In general not planning to bump those bounds unless there's a very clear use case. Not sure what your use case is, but if you need to use a cabal.config for a stackage snapshot, use one from LTS 9 because the bounds should work (an older nightly would also work). Alternatively, build stack from the source repo or the first hackage revision since neither of those have bounds set. On Dec 19, 2017 3:04 PM, "Dan Burton" <[email protected]> wrote: @peti <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACEGJVWb2nFNYe_kPl3wq7ujpMFDQDIRks5tCEEDgaJpZM4RGj0m> .

[snoyberg]

There is no way to use the cabal.config file to perform the builds, see commercialhaskell/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]

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

[fgaz]

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]

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

Since this is not a bug in Stackage, closing.

[peti]

@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]

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.