Unable to parse integer-gmp's Cabal file
integer-gmp version 1.0.1.0 has this line in its Cabal file: build-depends: ghc-prim ^>= 0.5.1.0
That uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error:
Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build-depends" 58
This was reported on Stack's issue tracker and on Reddit:
- https://github.com/commercialhaskell/stack/issues/3624
- https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/
I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead.
I can see how this isn't a bug per se because integer-gmp's Cabal file specifies cabal-version: 2.0
. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical cabal-version: >= 1.10
and specified its dependency as build-depends: ghc-prim >= 0.5.1 && <0.6
, without the caret operator.
Trac metadata
Trac field | Value |
---|---|
Version | 8.2.2 |
Type | Bug |
TypeOfFailure | CompileTimeCrash |
Priority | normal |
Resolution | Unresolved |
Component | Core Libraries |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Link issues together to show that they're related or that one is blocking others. Learn more.
Activity
- taylorfausak changed weight to 5
changed weight to 5
- taylorfausak added Tbug Trac import compiler crash core libraries labels
added Tbug Trac import compiler crash core libraries labels
In addition, I'm unable to find this format of the cabal file anywhere in GHC's git repo. Both master and ghc-8.2.2-release show an integer-gmp.cabal with cabal-version set to >= 1.10. At the very least, it seems like good practice to ensure that whatever is uploaded to Hackage matches the files GHC itself is shipping artifacts from.
- Herbert Valerio Riedel assigned to @hvr
assigned to @hvr
- Maintainer
Thank you for contacting GHC HQ. I'll look into this claim.
Trac metadata
Trac field Value TypeOfFailure CompileTimeCrash → OtherFailure - Herbert Valerio Riedel removed compiler crash label
removed compiler crash label
Trac metadata
Trac field Value CC - → snoyberg - Herbert Valerio Riedel closed
closed
- Maintainer
I'm happy to inform you the issue has been resolved and we've taken steps that will ensure this won't be an issue in the future anymore.
Trac metadata
Trac field Value Type Bug → Task Resolution Unresolved → ResolvedFixed - Herbert Valerio Riedel added Ttask label and removed Tbug label
If you haven't done so already, please also look at base-4.10.1.0\\ It has the same problem and it's the next thing stack will trip over after fixing integer-gmp
Can you clarify how this has been resolved? The file on Hackage and in 01-index.tar.gz both appear to still have cabal-version: 2.0, preventing Stack 1.5 from building with GHC 8.2. Also, it would be helpful to know what steps have been taken to ensure it won't happen in the future, and what led to this situation in the first place.
- Author
Seconding everything @snoyberg said. There are no new versions or revisions of integer-gmp. The current version/revision has not changed.
- Developer
@hsyl20 Thanks for pointing that out. If that was the referenced fix, it's definitely not what I had in mind. I believe this ticket should be reopened.
- taylorfausak reopened
reopened
- Author
Once again, I agree with @snoyberg. The problem is that integer-gmp requires Cabal 2. The fact that
integer-gmp.cabal
did not match what was in the Git repository was a problem (and I'm glad that it's fixed), but all it did was make debugging harder.Trac metadata
Trac field Value Resolution ResolvedFixed → Unresolved - Developer
If I understand this right:
- The versions of the library in GHC and the version in Hackage are now consistent; and the cabal files now specify Cabal 2 (which indeed they need).
- The remaining problem is that GHC now requires a bleeding-edge Cabal 2, and indeed ships with it. But that gives a problem for other downstream clients of GHC which may not have as recent a Cabal.
We should resolve (2) for the future. But meanwhile, I think (but I'm not certain) that we are stuck with it for 8.2. Is that right?
Re (2), leon, hsyl20, taylorfausak: did you encounter this problem because Stack was (understandably) not using a sufficiently up to date Cabal. Or did you have an independent reason why the change to the cabal file format caused you a problem? Thanks.
IMO (2) is no longer an issue now that the bug in Stack has been fixed.
- Reporter
@simonpj The versions of the library in GHC and the version in Hackage are not currently consistent. If I download ghc-8.2.1 from https://www.haskell.org/ghc/download_ghc_8_2_1.html and unpack it, the cabal file at
libraries/integer-gmp/integer-gmp.cabal
hasbuild-depends: ghc-prim
. However, the cabal file on hackage hasbuild-depends: ghc-prim ^>= 0.5.1.0
.In general, usage of this operator will break builds for anyone using older versions of build tools, regardless of whether it is cabal, stack, etc.
So, I would not say that the discrepancy has been resolved. I propose that a hackage revision be made to make the file match what is shipped with GHC. Alternatively, use plain ol normal version bounds.
Thanks!
- Author
(1) is correct. As far as I can tell, the Cabal files on Hackage match the Cabal files in the GHC repository. This is good and I'm happy that it happened, but it's not why I opened this ticket.
(2) is also correct. GHC and its built-in libraries require Cabal 2. This is obviously fine for GHC itself, but any downstream clients using GHC < 8.2 or Cabal < 2 are broken by this. (For example: https://github.com/tfausak/grawlix/commit/861f0f9d3f19ae9d94ce11b52311459e5a656534#commitcomment-25680505.)
I don't think we are stuck with this problem for 8.2. As far as Stack < 1.6.1 is concerned, revising the
integer-gmp-1.0.1.0
release or releasing a new version ofinteger-gmp
would fix things. Specifically, removing the caret constraint (and relaxing thecabal-version
) would allow older versions of Cabal and Stack to successfully parseinteger-gmp.cabal
. The patch is pretty small: https://github.com/ghc/ghc/commit/82aae8c81f5380af5f5ab9c381b1d296104696f4For what it's worth, I ran into this problem because Stack 1.5.1 ships with Cabal 1.24. I have fixed this problem for myself by upgrading to Stack 1.6.1. Anybody still using Stack < 1.6.1 will be broken if they try to use a snapshot with GHC >= 8.2. This includes anyone using the Haskell Platform, which bundles Stack 1.5.1.
Yes, I encountered this using stack-1.5.1, (at that time the latest stable version I believe). And I only encountered the same issue in base because I (tried to) setup my own hackage mirror to workaround this issue.
Now using stack-1.6.1 it all works again.
But the big surprise was that this upload of integer-gmp to hackage broke stack's promise of reproducible builds. (Even using snapshots dated well before the upload of integer-gmp)
- Reporter
Trac metadata
Trac field Value CC bergmark, mboes, snoyberg, steshaw → bergmark, mboes, mgsloan, snoyberg, steshaw - Developer
But the big surprise was that this upload of integer-gmp to hackage broke stack's promise of reproducible builds. (Even using snapshots dated well before the upload of integer-gmp)
Is this not a problem of stack? Should it not have been the one to guarantee that if it can't parse a package it does not enter it's system? If it makes such a guarantee it's up to it validate changes to preserve such guarantee. I don't understand how a new package can break LTS releases.
It's unrealistic to expect GHC to never change. We can guarantee backwards compatibility but not forward compatibility.
What I am missing here is why this is such a big deal. Yes the change was made by GHC upstream, yes it broke stack nightlies. But is it not the the purpose of nightlies to test the bleeding edge anyway?
This isn't the last time the format will change. Let's fix the tools to actually adhere to what is in the
cabal-version
fields and move on. IMO if Stack doesn't support the version of Cabal that ships with a certain version of GHC, it shouldn't claim that it supports that version of GHC. The same applies to
cabal-install
as well -- in the past, upgrading to a new version of GHC often required upgrading to a new version ofcabal-install
. There perhaps should be a warning on the GHC 8.2 download page that installing that version of GHC will require you to also upgrade Stack to 1.6.1+, like the download page warnings we had forcabal-install
in the same situation in the past.- Author
Clearly there was a bug in Stack. I'm not denying that. There was a bug in Stack, and it has been fixed. The solution for Stack users is to upgrade Stack. The core of my complaint and this ticket is:
it's frustrating that a core library is using a bleeding edge feature for basically no reason
It is demonstrably simple and easy to avoid using
^>=
constraints in core libraries. Doing so would ensure that the core libraries could be parsed with the greatest variety of tools. I think that is self-evidently good.As a thought experiment, consider what would happen if someone uploaded a
text-1.2.2.3
which was identical totext-1.2.2.2
except that it specifiedcabal-version: >= 2.0.1.1
instead ofcabal-version: >= 1.8
. Obviously the maintainers are well within their rights to make such a change. I am trying to argue that making a change like that is unnecessary and irresponsible. If such a change was made, I would encourage the maintainers to revert it. That's what I'm doing here. If it was something like
text
ordirectory
(which comes with GHC), or evenCabal
itself, where it makes sense to upgrade them if you're running an old GHC version, I'd be against that as well. But in the case of a small number of wired-in non-upgradeable libraries likebase
andinteger-gmp
, an additional obstacle like this is actually a good thing. The solver incabal-install
also goes out of its way to prevent users from trying to reinstallbase
andinteger-gmp
.- Developer
I wouldn't even care if it was
text
ordirectory
. I have a pretty clear stance on this to prevent hampering our ability to make progress in the future. If you have a technical merit for the reasons you don't like^>=
than that is something we would listen to. However because you don't see the use of it doesn't mean it's wrong to use it.Using
^>=
has a clear benefit, and maintainers are free to use any features that's in the cabal file.Secondly like
refold
said,integer-gmp
is a special build-in in that it requires build system support for systems using in-tree gmp. So there is a number of configurations that would break if you were to try to install theinteger-gmp
package.If you follow the dependency chain you'll notice it depends on
GHC-prim
which is compiler specific, which further depends on therts
package, which will soon also be a cabal package. Their presence on Hackage as far as I am aware are only for resolvers. You can't actually install them short of getting a new GHC version.Because of this, it is perfectly reasonable to use new bleeding edge features in these packages. As they are literally tied to GHC, and you should not be swapping them out/mixing and matching them. We don't guarantee ABI stability for them at all.
I think we should learn from this experience. There was a non backwards compatible change in the cabal format. It may have been the first, but it won't be the last. Let's constructively find a way to prevent things from breaking in the future. Arguing about whether a library is allowed to use the bleeding edge isn't useful, the tools should handle this gracefully.
and unless I'm mistaken, don't both
stack
andcabal-install
do this now? Replying to [ticket:14558#comment:146000 Phyx-]:
[...] Using
^>=
has a clear benefit, and maintainers are free to use any features that's in the cabal file. [...]What is that "clear benefit"? It surely can't be saving roughly ten keystrokes. As I understand it, it is just (IMHO superfluous) syntactic sugar. If it's not, there should be a big announcement with some clarifications and the underlying rationale somewhere on the Haskell mailing lists. The cabal file syntax is at the core of the Haskell ecosystem, so everybody involved should have a clear understanding of its semantics.
- Developer
Replying to [ticket:14558#comment:146001 svenpanne]:
What is that "clear benefit"? It surely can't be saving roughly ten keystrokes. As I understand it, it is just (IMHO superfluous) syntactic sugar. If it's not, there should be a big announcement with some clarifications and the underlying rationale somewhere on the Haskell mailing lists. The cabal file syntax is at the core of the Haskell ecosystem, so everybody involved should have a clear understanding of its semantics.
It was announced, about 3 months ago, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html along with the future intention of this syntax and how it differs from the strong bounded versions:
New caret-style version range operator ^>= (#3705 (closed)) that is equivalent to >= intersected with an automatically inferred major upper bound. For example, foo ^>= 1.3.1 is equivalent to foo >= 1.3.1 && < 1.4. Besides being a convenient syntax sugar, ^>= allows to distinguish “strong” and “weak” upper bounds: foo >= 1.3.1 && < 1.4 means “I know for sure that my package doesn’t work with foo-1.4”, while foo ^>= 1.3.1 means “I don’t know whether foo-1.4, which is not out yet, will break my package, but I want to be cautious and follow PVP”. In the future, this feature will allow to implement automatic version bounds relaxation in a formally sound way (work on this front is progressing on matrix.hackage.haskell.org). See this section of the manual for more information.
It was designed and approved in public https://github.com/haskell/cabal/pull/3705 it was publicly posted on reddit https://www.reddit.com/r/haskell/comments/6z2gja/whats_new_in_cabalcabalinstall_20_improved/
And the migration plan was outlined https://github.com/haskell/cabal/issues/4899.
Could it be that perhaps a lot of people here don't read Cabal release information? Or follow Cabal development? At least taylorfausak can't possibly be surprised by it because he was even fighting with hvr about it in the reddit thread.
FYI, it's also in the package changelog https://www.haskell.org/cabal/release/cabal-2.0.1.1/changelog which is linked to from https://www.haskell.org/cabal/download.html . The post never made it to the homepage due to some bikeshedding https://github.com/haskell/cabal-website/issues/3.
It was also announced on twitter https://twitter.com/refold/status/906547449329831936
So I fail to see how any of this could have come at such a big surprise to anyone.
The fact is, the change was not done in secret, the feature not developed in secret. The change was communicated well ahead of time and on channels that lots of you frequent.
- Developer
And I want to make this absolutely clear. In case there is any doubt at all. While I am not a user of stack, I have nothing against stack. It solves a problem many people have.
However if you depend on an upstream project, it is your responsibility to keep track of it's development. There are plenty of ways to do so. Just like there were plenty of times before this where stack people could have worked together with Cabal people to form a migration plan. After the announcement would have been one such occasion.
However as far as I can see, no one did so. If we don't get any feedback, we will assume there is no objection.
The problem is this us vs you mentality that has somehow evolved. My changes to GHC at no time involve thinking about how to break stack. Despite all the assertion that our free time, which many of us willingly donate to help GHC is spent actively trying to sabotage another project.
- Author
Come on y'all. I'm trying to avoid turning this into an us versus them argument for all values of us and them. The problem described in this ticket affects people trying to install GHC >= 8.2 with Stack < 1.6.1. It also affects people like me who want to parse the package descriptions of the core libraries without depending on bleeding edge Cabal features.
I'm also trying to avoid arguing about the
^>=
operator itself. We have a new operator, it's been talked to death, people are going to use it. Currently^>= x.y.z
is syntactic sugar for>= x.y.z && < x.(y+1)
. In the future, Hackage trustees may be able to make changes to^>=
constraints because they are "soft".That brings me once again to the crux of this ticket:
it's frustrating that a core library is using a bleeding edge feature for basically no reason
Is there a compelling reason for
integer-gmp
to use^>=
? It has already been demonstrated that using^>=
causes problems. I will happily close the ticket and be on my merry way if someone can say: "Yes,integer-gmp
(or any core library) needs^>=
(or any Cabal 2 feature) because //X//." I have not heard such a reason yet. It seems to me that the GHC developers are refusing to make a simple fix that will solve a problem for a large number of users.Also I'm having a hard time wrapping my head around why the
^>=
operator would ever be necessary for core libraries. As many people have pointed out in this ticket,integer-gmp
cannot be reinstalled. So any revisions to its package description are essentially ignored. The whole point of^>=
, as far as I can tell, is to allow Hackage trustees to revise the bounds if new valid build plans are discovered. That means using^>=
ininteger-gmp
only saves a few keystrokes at best. Replying to [ticket:14558#comment:146002 Phyx-]:
It was announced, about 3 months ago, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html along with the future intention of this syntax and how it differs from the strong bounded versions: [...]
Hmmm, this is still confusing: On the one hand it is said (https://www.haskell.org/cabal/users-guide/developing-packages.html?highlight=caret#pkg-field-build-depends) that the new syntax is exactly equivalent to the old syntax using
>=
and<
. OTOH, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html states that it has different semantics.Furthermore, I still don't get the difference between the new
^>=
operator and leaving out the upper bound completely. Surely the latter can't really mean "I promise I work with every following version", in the absence of clairvoyant abilities this would be a lie. So using only>=
without an upper bound seems to be equivalent to the new operator, I fail to see another sensible interpretation.[...] It was designed and approved in public https://github.com/haskell/cabal/pull/3705 it was publicly posted on reddit https://www.reddit.com/r/haskell/comments/6z2gja/whats_new_in_cabalcabalinstall_20_improved/
And the migration plan was outlined https://github.com/haskell/cabal/issues/4899.
Perhaps I'm getting a little bit old, but I consider neither reddit nor twitter as a source of serious information. Nothing was posted on the haskell, haskell-cafe or ghc-dev mailing lists about it. The only thing I was able to find was a Haskell Weekly issue pointing to the blog, having the feature buried in the middle of a multi-page item list, which is a bit indirect IMHO.
Could it be that perhaps a lot of people here don't read Cabal release information? Or follow Cabal development? [...]
Serious non-aggressive question: As a developer using only stack, why should I read the Cabal release information or even follow Cabal development? Note that I am not hostile towards the project or something like that, it's just that I am not interested in it anymore because stack is a much better fit for my work. My expectation from a library developer POV would be some explicit hint about changes in the ecosystem, not about changes in some tool I don't use.
[...] The fact is, the change was not done in secret, the feature not developed in secret. The change was communicated well ahead of time and on channels that lots of you frequent.
As mentioned above, I think it would have been great if this had been posted on one of the Haskell mailing lists, which I still consider the channel to get information from. Not everybody has the time and energy to read all those various (and most of the time uninformative and time sucking) communication channels which beg for your attention... :-/
I'm feeling like we're starting to go in circles here. If the only remaining concern is better UX for the users of a legacy version of Stack trying to force it into an unsupported configuration, then I can suggest the following steps:
- Write a patch for Stack that makes it print a warning when a user tries to use it with a version of GHC that is not in the whitelist of supported and properly tested versions. In general, using a version of GHC with a version of Cabal earlier than the one that ships with that GHC release is not a good idea and has been known to break in the past.
- Cut a new release from the 1.5 branch that includes this patch.
- Add a warning to the GHC download page that tells the users of Stack < 1.6 that they should upgrade.
Otherwise I fear there's a high chance that this situation will repeat itself when the users of legacy versions of Stack will try to use it with GHC 8.4 or 8.6.
It also affects people like me who want to parse the package descriptions of the core libraries without depending on bleeding edge Cabal features.
By the same logic,
base
andinteger-gmp
shouldn't be allowed to use the latest GHC features because you might want to parse them withhaskell-src-exts
.Replying to [ticket:14558#comment:145981 Phyx-]:
Is this not a problem of stack?
Oh my... This is *exactly* the line line of reasoning that gets firebrand shaming from Linus Torvalds on LKML. I wish we were to follow it in spirit if not in, ahem, letter.
No, this is not a problem of "stack" (or any other cabal-parsing tool out there). It's a problem of trust and communication. "Not my problem" is how we get into all this and still can't get out.
What I am missing here is why this is such a big deal.
Even a fringe library author should constantly ask themselves: "How many people this change would affect? Am I communicating this adequately?". And here we get major revision in core libraries.
Let's fix the tools to actually adhere to what is in the
cabal-version
fields and move on.You can't just go and "fix" tools that are already deployed. Switching package version is a no-brainer for a hobby project, but will require major intervention at a company level. And that requires not only downloading a tarball, but examining all the changelogs and open issues.
This is how Docker people are getting sneered upon in their "all right, a new version. go do the upgrade dance, everyone!".
You can't just go and "fix" tools that are already deployed.
If legacy version users apparently are able to upgrade to new versions of GHC, why is it so hard for them to run
stack upgrade
? Already deployed stable configurations should continue to work.Already deployed stable configurations should continue to work.
Unfortunately that's not the case. There were two issues that popped up in parallel here:
- The cabal file uploaded to Hackage differed from the one in the GHC release tag, and broke compat with Cabal 1.24
- The cabal file was uploaded months after that GHC version was in circulation
Any installation using GHC 8.2.1 and Stack 1.5.1 was broken when this upload occurred on December 4.
OK, but then you want a Hackage revision and not a patch for the upstream repo? I think the former can be arranged, but then it's off-topic for the GHC bug tracker.
Already deployed stable configurations should continue to work.
Unfortunately that's not the case.
And as Phyx mentioned above, GHC 8.2 is not a part of any LTS release, so IMO that statement of mine remains correct.
I think the former can be arranged, but then it's off-topic for the GHC bug tracker.
Where would be the right place to file issues like this? Since integer-gmp is part of GHC, I would have guessed that this is the best place to report. Perhaps the integer-gmp.cabal file needs to be modified to include an issue tracker URL?
And as Phyx mentioned above, GHC 8.2 is not a part of any LTS release, so IMO that statement of mine remains correct.
I disagree; Stackage Nightly is not intended to have the same level of stability as an LTS release, but:
- We strive for a high level of stability, and
- In this case, a cabal file was uploaded to Hackage months after the release of GHC, which caused problems down the line. I'd like to understand the process that allowed this situation to occur, and ideally ensure that it doesn't happen in the future. We're not that far away from an LTS release including GHC 8.2. If the upload occurred in February instead, we may have been facing this bug with an LTS release.
To quote myself from above:
Can you clarify how this has been resolved? The file on Hackage and in 01-index.tar.gz both appear to still have cabal-version: 2.0, preventing Stack 1.5 from building with GHC 8.2. Also, it would be helpful to know what steps have been taken to ensure it won't happen in the future, and what led to this situation in the first place.
There's still not been any real answer to any of these points; Herbert simply stated that the issue has resolved and won't occur in the future. We're assuming that by resolved he means that the file was updated in the Git repo (though it doesn't address the tagged release), and still don't know what "we've taken steps that will ensure this won't be an issue in the future anymore" means.
- Herbert Valerio Riedel closed
closed
- Maintainer
Thanks for everyone's feedback on this issue. However, at this point the discussion is starting to go in circles and maybe we'll just have to agree to disagree; so I'll try to summarise what I consider technically relevant for the issue at hand and deliberately ignore the politically motivated aspects^(Those can be discussed elsewhere as the GHC issue tracker is obviously not the right venue)^ and subsequently close this ticket in order to move on:
-
GHC 8.2.x goes together with Cabal 2.0.x (which both have been released 5 months ago, which I hardly consider bleeding edge).
-
The compability story of GHC/Cabal has traditionally build upon the principle that the build tool fully supports the lib:Cabal version bundled with GHC; everything else is not an officially supported configuration. period. As such, Stack-1.5.1 does not deserve the label "supports GHC 8.2".
-
Similarly, it's not reasonable to expect to be able to parse
.cabal
files destined for the latest GHC release with an older lib:Cabal version than the one co-developed with/for that GHC release, as we cannot easily predict the future. -
As pointed out, this merely affects the unstable branch, i.e. Stackage Nightlies, not the stable "Long Term Support" snapshots.
-
The issue at hand doesn't impede Stack-1.5.1 users from conveniently upgrade via
stack --upgrade
and get Stack-1.6.1 which is the first Stack release that can honestly claim to "support GHC 8.2" (even if it took merely 5 months to get there). -
Stack-1.5.1 is a lost cause anyway as modern
.cabal
files will inevitably keep entering the package index. -
Going forward, we now have https://github.com/haskell/cabal/issues/4899 in place which will prevent this from repeating in the future. This way we don't have to hold back Hackage/GHC/Cabal's development for tooling to catch up; in fact, 3rd party tooling can catch up at their own convenience, even if it takes half a year, which is not uncommon in the OSS world. (PS: Moreover, I'll make sure to upload GHC's core libraries to Hackage in a more timely manner, ideally same-day, in the future.)
I'm aware that we may have to agree to disagree on some aspects. But please, let's move on.
Trac metadata
Trac field Value Resolution Unresolved → ResolvedFixed -
@snoyberg If you want a Hackage revision for
integer-gmp
, I think the right place to discuss that is thehackage-trustees
bug tracker. On the topic of what steps were taken to prevent tarballs of core libs on Hackage from differing with official GHC releases, I'll leave it to Herbert to answer.BTW, can Stack < 1.6 users also work around this by reverting to a pre-Dec 04 nightly snapshot?
- Author
Once again I am sad to see this ticket closed without any fix put in place. I am also disappointed in the behavior of GHC developers who appear to be breaking downstream tools and making absolutely no concessions to them. Needless to say, this entire experience has not been positive. I'll leave you with some assorted thoughts:
-
As has been stated repeatedly in this thread, one of the problems is that build plans that used to work have stopped working. Anybody trying to use a GHC >= 8.2 snapshot with Stack < 1.6.1 will be unable to do so.
-
integer-gmp
does not have its own bug tracker. As I said when I opened this ticket: "I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead." I asked @hvr on Twitter where to reportinteger-gmp
bugs and he said I should report them to him directly. https://twitter.com/taylorfausak/status/938243186237083649 -
In my opinion, Stacakge nightlies aren't "unstable". Furthermore, knowingly breaking them is at best inconsiderate and at worst hostile.
-
It did not take Stack 5 months to support GHC >= 8.2. I have been using Stack with GHC 8.2 since the release candidates. Stack's support of GHC 8.2 was broken by @hvr's package uploads on December 4.
-
integer-gmp
's Cabal file has been updated on theghc-8.2
branch of the GHC repository, but it has not been updated on theghc-8.4
branch. Perhaps we'll end up in a situation where the repo doesn't match Hackage again.
I find myself once again repeating the crux of this ticket:
it's frustrating that a core library is using a bleeding edge feature for basically no reason
I haven't seen anyone even attempt to explain why
integer-gmp
needs to use^>=
bounds. The argument seems to be that it can, so why not? I think "not breaking other tools" is a pretty compelling reason not to. Apparently GHC developers think breaking other tools is an acceptable price to pay for saving 8 characters in a single Cabal file. -