[GHC] #14558: Unable to parse integer-gmp's Cabal file
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- integer-gmp version 1.0.1.0 has this line in [https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal 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_... 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr * failure: Compile-time crash or panic => None/Unknown Comment: Thank you for contacting GHC HQ. I'll look into this claim. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by steshaw): * cc: steshaw (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bergmark): * cc: bergmark (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * type: bug => task Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by leon): 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 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Seconding everything @snoyberg said. There are no new versions or revisions of integer-gmp. The current version/revision has not changed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): It seems that only comment:1 has been "fixed": * https://git.haskell.org/ghc.git/commitdiff/5f332e1dab000e1f79c127d441f618280... * https://git.haskell.org/ghc.git/commit/3fa061a647d2fdc182eff9296eea02d6a7d51... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): @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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by taylorfausak): * status: closed => new * owner: hvr => (none) * resolution: fixed => Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If I understand this right: 1. 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). 2. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): IMO this is no longer an issue now that the bug in Stack has been fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): @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` has `build- depends: ghc-prim`. However, the cabal file on hackage has `build- depends: ghc-prim ^>= 0.5.1.0`. It seems quite illogical that the versions of the packages would match, but their metadata would be different. It also is extremely puzzling why a new and experimental Cabal syntax feature, which is essentially syntax sugar, is being used in a core package. In the general case, usage of this operator will break builds for anyone using older versions of build tools, whether it is stack or cabal. So, I would not say that the discrepancy has been resolved. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): (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/861f0f9d3f19ae9d94ce11b52311459e5a....) 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 of `integer-gmp` would fix things. Specifically, removing the caret constraint (and relaxing the `cabal-version`) would allow older versions of Cabal and Stack to successfully parse `integer- gmp.cabal`. The patch is pretty small: https://github.com/ghc/ghc/commit/82aae8c81f5380af5f5ab9c381b1d296104696f4 For 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by leon): 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) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-):
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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tehnix): * cc: tehnix (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): 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 of `cabal-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 for `cabal-install` in the same situation in the past. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): 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 to `text-1.2.2.2` except that it specified `cabal-version: >= 2.0.1.1` instead of `cabal-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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): If it was something like `text` or `directory` (which comes with GHC), or even `Cabal` 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 like `base` and `integer-gmp`, an additional obstacle like this is actually a ''good'' thing. The solver in `cabal-install` also [https://github.com/haskell/cabal/blob/master/cabal- install/Distribution/Solver/Modular/Solver.hs#L127 goes out of its way] to prevent users from trying to reinstall `base` and `integer-gmp`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I wouldn't even care if it was `text` or `directory`. 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 the `integer-gmp` package. If you follow the dependency chain you'll notice it depends on `GHC-prim` which is compiler specific, which further depends on the `rts` 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` and `cabal-install` do this now? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:26 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Replying to [comment:27 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.
= 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
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) that is equivalent to 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_cabalcabalinst... 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): 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 `^>=` in `integer-gmp` only saves a few keystrokes at best. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
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
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:28 Phyx-]: 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_cabalcabalinst...
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... :-/ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold):
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` and `integer-gmp` shouldn't be allowed to use the latest GHC features because you might want to parse them with `haskell-src-exts`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dpwiz): Replying to [comment:21 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!". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold):
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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg):
Already deployed stable configurations should continue to work.
Unfortunately that's not the case. There were two issues that popped up in parallel here: 1. The cabal file uploaded to Hackage differed from the one in the GHC release tag, and broke compat with Cabal 1.24 2. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): 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 its off-topic for the GHC bug tracker. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold):
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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg):
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: 1. We strive for a high level of stability, and 2. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: 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 those elsewhere as the GHC issue tracker is obviously not the right venue)^ and close this ticket: - 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 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 "supports GHC 8.2" (even if it took merely 5 months to get there) - Stack-1.5.1 is a lost cause anyway modern as `.cabal` files will inevitably enter 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. I'm aware that we may have to agree to disagree on some aspects. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): If you want a Hackage revision for `integer-gmp`, I think the right place to discuss that is the `hackage-trustees` bug tracker. On the topic of what steps were taken to prevent tarballs on Hackage from differing with official releases, I'll leave it to Herbert to answer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): BTW, can Stack < 1.6 users also work around this by reverting to a pre-Dec 04 nightly snapshot? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): 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 report `integer-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 the `ghc-8.2` branch of the GHC repository, but it has not been updated on the `ghc-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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:43 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
Once again I am sad to see this ticket closed without any fix put in
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @taylorfausak place. If you want a Hackage revision for `integer-gmp-1.0.1.0`, I suggested a path forward. Is there any other fix that can be applied to provide better UX for users of Stack < 1.6.1? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Indeed, I opened a Hackage trustees issue: https://github.com/haskell- infra/hackage-trustees/issues/120 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:45 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Great! I'm glad that we've finally found a way forward. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold):
BTW, can Stack < 1.6 users also work around this by reverting to a pre- Dec 04 nightly snapshot?
@taylorfausak answered that question in the `hackage-trustees`: apparently old snapshots also break. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:47 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: hvr => (none) * status: closed => new * resolution: fixed => Comment: For me, an important principle is this: * '''GHC should strive to make life as easy as possible for downstream tools''' One way to make life easy is never to make any changes: eternal backward-compatibility. No one is asking for that. But once we leave that extreme there's a continuous spectrum of choices, and we have to strike a balance. For example, in the language design, and library changes, we go to much effort to avoid breaking downstream libraries and tools, except when there is no alternative -- and even then we try to offer plenty of notice and workarounds. I'm not familiar with all the technical issues on this thread, but I can see that there is at least a perception by some that we have caused unnecessary breakage --- breakage that I didn't even know GHC ''could'' cause. Far from making no concessions, I think the GHC developers should be very open to making concessions to better support GHC's user community. I'll have a chat with Ben, Simon, Herbert and others, to see how best to move forward. But meanwhile I wanted to state the principle explicitly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Thank you @simonpj! I am very happy to hear that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:49 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): It should be noted btw that the issue on hackage-trustees was resolved with a revision of the file in question. So if this ticket is kept open for tracking broader questions then that's one thing -- but the concrete immediate issue raised seems to have been satisfactorily resolved. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:50 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dpwiz): What if there was a dedicated place for announcing breaking changes, gathering feedback, stating blockers and prompting to hurry? I read a lot of arguments on the net stating "they said; no we didn't; yes but..." etc. Maybe a public audit trail for decisions like this will help to prevent good portion of the drama. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14558#comment:51 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC