-
Notifications
You must be signed in to change notification settings - Fork 841
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 broken by latest integer-gmp #3624
Comments
#3464 mentions that Cabal 2 syntax is not allowed in Stackage packages. However, |
The problem is that integer-gmp is included with GHC itself. This has a long history, quick summary:
In other words, this will be fixed permanently with the upcoming release. |
Is there a work-around for 1.5.1 given the current state of Hackage?
Perhaps there are older Hackage indices somewhere that can be pointed to?
If not I suppose using stack built from master is the way to go?
This is quite frustrating brittleness, especially if it turns out that
stack 1.5.1 and previous are permanently bricked by this change. It was
surprising to find that such a change in the Hackage index not only broke
reproducibility, but broke the tool itself without easy recourse short of
copying a colleague’s local index. I’m sure my non-Haskeller colleagues
whose code has Haskell dependencies are even more surprised to be blocked
on this.
…On Mon, Dec 4, 2017 at 8:43 PM Michael Snoyman ***@***.***> wrote:
The problem is that integer-gmp is included with GHC itself. This has a
long history, quick summary:
- Stack through version 1.5.1 was too eager to parse Cabal files
- The work for extensible snapshots accidentally fixed this, and then
we added a test case in #3396
<#3396> to ensure it
stayed that way
- With GHC-8.2.1, the only problem was ghc.cabal, so we made a patch
release Stack 1.5.1 to work around that limitation with PR #3304
<#3304>
In other words, this will be fixed permanently with the upcoming release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3624 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABP-u5dvG2U7rol3eavv9GdDe5Vvn1pHks5s9MoGgaJpZM4Q1gSA>
.
|
Maybe I misunderstood. I thought this would only cause trouble if you try using a newer Stackage Nightly snapshot. Are you saying that Stack is broken for all cases, even if you aren't using a GHC 8.2.2 snapshot? |
Ah, it seems if you're on a snapshot with GHC 8.0.2 or earlier things are fine (makes sense seeing #3396); a colleague reported this breakage with LTS 9 but I wasn't able to reproduce it just now. I do get this issue with the 8.2.1 nightlies (11/24 and previous). If If I understand correctly, the Cabal 2 syntax will make stack 1.5.1 effectively unusable with the GHC 8.2.* snapshots, is that correct? What a mess this whole |
I'm confused about integer-gmp-1.0.1.0, I don't know how it would have affected the 8.2.1 nightlies without further research. But the basic idea is: if a package in a snapshot takes advantage of a new Cabal feature, then older Stacks will have no way of using it. We can try to work around it by blocking such packages in Stackage, but we can't do anything about packages shipped with GHC itself. I've requested that some time be taken to allow tooling to upgrade before we start using new features, but that request was denied.
You don't know the half of it :( For example, see #3464. |
I just ran into this problem. I'm on Windows using Stack 1.5.1 and the nightly 2017-12-01 resolver. I understand that integer-gmp is at fault for using the new |
We're hitting this problem with integer-gmp-1.0.1.0 in our CI as well. As with the OP we also seem to observe this even when reverting to the 11/24 8.2.1 nightly (which had previously been working). |
I created a ticket on GHC's Trac for this: https://ghc.haskell.org/trac/ghc/ticket/14558 |
How do I subscribe to the GHC#14558 over on GHC Trac? |
@steshaw Click on "Modify Ticket" and add your name to the "CC" field, then click "Submit changes." And for the record: I find that workflow really confusing :) |
Thought I'd pick up on @TravisWhitaker's note about broken reproducibility. We have a working build of our app on CircleCI using - ~/.stack
- .stack-work/downloaded
- .stack-work/install I only noticed this So, I imagine that the metadata for If I'm not mistaken, the issue of reproducibility in the face of hackage metadata updates has been raised in #2217. Perhaps this problem "in the wild" with |
I didn't think about this before, but the recent upload date (two days ago) made me think of something. I pinged @hvr on Twitter two days ago because I didn't see I don't have an explanation for why the new version of |
Thanks, @tfausak, there doesn't seem to be a link to So, I take it that the |
The link only shows up if there are any revisions. For example,
You can read more about revisions in the hackage-trustees repository. I'm not a fan of them, but they didn't cause this particular problem. |
Stackage currently specifies specific revisions as well, so revisions shouldn't break reproducibility. I'm also unsure of how this made it into the nightlies. Guessing the process there already used Cabal-2.0. Ideally the process would use the latest stable stack. |
This is a temporary workaround for commercialhaskell/stack#3624.
The ChangeLog update included in #3304 explains what's happening here: https://github.com/commercialhaskell/stack/pull/3304/files#diff-e705c8fadf1193ab59443a5e6c8cbe8bR4. GHC includes a number of libraries in its package database, including When GHC 8.2.1 was released, the For unrelated reasons, I'd already fixed this bug on master as part of a refactoring. Strangely enough, that refactoring had to do with problems with revisions. Thanks to the revision system, it's not possible to rely on cabal files on Hackage to tell you anything about GHC-installed packages, since we can't know for certain which revision was used to build the package. (The situation with integer-gmp is even worse in this regard, since the uploaded cabal file appears nowhere in GHC's Git repository. It seems to have been manually altered for the purposes of uploading to Hackage, for reasons that are not clear.) Anyway, with GHC 8.2.1, we released an emergency patch release of Stack to work around this situation and simply ignore parse failures from
What we didn't anticipate was that a package that had been part of GHC's installed database would be manually modified and uploaded to Hackage after the fact. Before this upload, the missing Finally: the general case of Stack being unable to parse some snapshots is not a bug, it is guaranteed to happen. At some point in the future, Stackage will allow Cabal 2.0-formatted cabal files into snapshots, and then by design Stack 1.5 and earlier will be unable to parse those files. That's unfortunate, but expected. What's unexpected in this case was that (1) these cabal files slipped into a snapshot through the back door (GHC's package database) so quickly, before Stack 1.6 was out the door, and (2) that actions taken post-GHC release (a new upload of integer-gmp.cabal) could affect existing snapshots. So in sum:
I hope that clarifies. This is definitely an unfortunate situation, and I know it's screwed up people's development. If it's any consolation, Cabal 2.0 related issues have taken up a larger portion of my life than I ever would have hoped for. |
Hi @snoyberg, thanks for the detailed explanation. I was digging around and too noticed that I'm still curious why I got an initial green build. This build happened after the upload of BTW, this bug hasn't been a hassle for our development here. We were just testing our code against GHC 8.2.2 for hopeful upgrade of our master branch at some point soon (once a Stackage LTS is out). GHC 8.2.2 does compile our Yesod-based app a bit quicker so we're looking forward to it 😄 . I've also tested our build with |
Most likely the reason it only popped up locally is that, on CI, it was using a cached version of the |
Uses GHC 8.0.2 Partial work around commercialhaskell/stack#3624
This reverts 5afdb22 now that commercialhaskell/stack#3624 is fixed.
See haskell-infra/hackage-trustees#120 - happily, this is now resolved, as a revision to integer-gmp has been made - https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revisions/ . |
A few hours ago
integer-gmp-1.0.1.0
was uploaded to Hackage. The new package's cabal file'sbuild-depends
field uses the new^>=
syntax for version specification. The stable release (v1.5.1) doesn't use Cabal 2, so if you're working with a fresh index stack (any operation butstack update
, it seems) will fail withUnable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build-depends" 58
. This seems to occur in all of my stack projects, no matter which snapshot is selected.To reproduce (in some stack project's directory):
I'll note that all of the stack projects I've tried this with have non-emptySeems this happens even without anyextra-deps
fields; perhaps stack functions correctly without checking the Hackage index if there are noextra-deps
specified?extra-deps
.If I've got something wrong here or if someone is aware of a workaround that isn't copying another machine's index, please do share.
The text was updated successfully, but these errors were encountered: