search

haskell-pkg-janitors / haskell-src

Library for manipulating Haskell source code
http://hackage.haskell.org/package/haskell-src
Other
22 stars 13 forks source link

Upgrade to GHC 8.8.1 #8

Closed andreasabel closed 5 years ago

andreasabel commented 5 years ago

haskell-src does not build with ghc 8.8.1:

$ cabal install haskell-src
...
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: haskell-src-1.0.3.0 (user goal)
[__1] next goal: base (dependency of haskell-src)
[__1] rejecting: base-4.13.0.0/installed-4.1... (conflict: haskell-src =>
base>=4.3 && <4.13)
...

HTF depends on haskell-src, for instance.

hvr commented 5 years ago

Addressed by https://hackage.haskell.org/package/haskell-src-1.0.3.1

andreasabel commented 4 years ago

Thanks!

May I ask why the new release supports ONLY ghc 8.8? https://matrix.hackage.haskell.org/#/package/haskell-src The constraint on base is >= 4.13, but on the other hand, the cabal file says:

tested-with: GHC==8.4.1, GHC==8.2.2, GHC==8.0.2, GHC==7.10.3, GHC==7.8.4, GHC==7.6.3, GHC==7.4.2, GHC==7.2.2, GHC==7.0.4

(That seems not fully up-to-date, missing 8.8 and 8.6).

Is this an oversight? Was the intention to put base >= 4.3, like it is on github? https://github.com/haskell-pkg-janitors/haskell-src/blob/9f473b6c8ad5806799fda7871d856d9ca4f212f7/haskell-src.cabal#L39

I am asking since I have problem installing haskell-src as a dependency of HTF in my travis test for BNFC on ghc 8.8: https://travis-ci.org/BNFC/bnfc/jobs/622005387

next goal: haskell-src (dependency of HTF-0.14.0.1)
rejecting: haskell-src-1.0.3.1 (unsupported spec-version 2.4)

The culprit seems to be that haskell-src-1.0.3.1 asks for cabal-version: 2.4, unlike the current HEAD, which just wants cabal-version: >=1.10.

I fail to understand why the released version on hackage differs from the current HEAD. (On the other hand, I am not a cabal expert.) What would go wrong if the latest HEAD (which does not have all the tight bounds) was released on hackage as 1.0.3.2 ?

hvr commented 4 years ago

@andreasabel The haskell-src-1.0.3.1 release has been done in this particular way deliberately and it's a pattern I've started for some time now; specifically I try to avoid nedlessly exploding the build-plan configuration space to avoid useless degrees of freedoms, especially if the new release has been done for the sole purpose and benefit of supporting a new major GHC version. I've meaning to document this recommended practice but never got around to it; it's very related to the concepts that underly the recommendations in https://github.com/haskell-infra/hackage-trustees/blob/master/cookbook.md#best-practice-for-managing-meta-data

Also, you might notice that the haskell-src-1.0.3.1 release was done from the https://github.com/haskell-pkg-janitors/haskell-src/tree/1.0.3._ maintenance branch I created for this very purpose (also in case a future GHC release needs yet another release that can't be addressed by a simple meta-data update); that's why there is this apparent divergence w/ master; the master branch is intended for the the next minor or major version of haskell-src which will support a wider range of GHC versions again.

neongreen commented 4 years ago

I have to say that this practice is rather intuition-breaking. If I stumbled upon https://hackage.haskell.org/package/haskell-src on Hackage, I would definitely make a mental note "okay, this package probably depends on latest GHC features or something so I can't use it, moving on". It would not occur to me that I should look at 1.0.3.0 or further in the past.

hvr commented 4 years ago

@neongreen sure, but why would you have two releases for the same minor version then? i.e. you have two releases that expose the very same API (otherwise they wouldn't be allowed to share the same minor API version), and by definition micro-releases are supposed to be a way to make internal changes not observable by API consumers which say depend on haskell-src == 1.0.3.* -- this gives us the ability to avoid CPP completely in packages and the solver pick the compatible micro-release that satisfies constraints. This technique is rather old, and was also for instance used for discriminating over the version of transformers used in http://hackage.haskell.org/package/transformers-compat-0.6.0.2 through 0.6.0.6 -- an API consumer would depend on transformers-compat == 0.6.0.* and the cabal solver would pick the micro-release that matches the version of transformers. I think the intuition needs to evolve otherwise we would risk being held back from being more creative in finding ways to exploit the features available to us by virtue of having a proper constraint-solver at our disposal that is able to compute a lot more than other ecosystems are able to which are limited to far more basic update problems...

neongreen commented 4 years ago

Sure, but "being creative" vs. "being boring and predictable" is a tradeoff – and I just wanted to give you an extra data point for balancing the tradeoff.

For what it's worth, I also had no idea that transformers-compat-0.6.0.x was using this technique – I thought it was done by the Cabal solver juggling the two, three, etc flags (and never looked into details).

Perhaps it would help if Hackage allowed prominently marking all "active" versions of a package when there is more than one.