haskellPackages.ghc: 8.10.7 -> 9.0.2 #160733
Conversation
sternenseemann
requested review from
cdepillabout,
maralorn and
expipiplus1
as code owners
ofborg
bot
added
8.has: clean-up
8.has: package (new)
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/call-for-contributions-we-are-updating-to-ghc-9-0-2/17844/1 |
|
I don't think we could be able to update |
That's a good hint, thanks! Also has the benefit that it'll enforce some base packages to work in the 8.10.7 set, so it'll stay usable longer hopefully. Do you know if there's any plans to migrate to 9.0 at some point on upstream's side? |
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
This commit has been generated by maintainers/scripts/haskell/update-stackage.sh
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
|
@sternenseemann unfortunately compiler work is rather opaque. The last version of compiler was released in 2019 https://github.com/elm/compiler/releases/tag/0.19.1 and the most recent information from the end of last year is that new version won't be ready soon even though it's being worked on https://discourse.elm-lang.org/t/status-update-3-nov-2021/7870 I think pinning the ghc 8 for elm will be more reasonable than trying to patch around it. I can try to look into this in separate PR if you want me to since fixing ghc just for elm can be done and merged separately. edit: also we build elm as static binary so I think there is no significant disadvantage to decoupling it from default Haskell package set. |
|
@turboMaCk That'd be appreciated! I tried the following patch locally just now and it seems some dependencies of elm will need looking at still (e.g. currently it's failing of something claiming to not support attoparsec 0.14): diff --git a/pkgs/development/compilers/elm/default.nix b/pkgs/development/compilers/elm/default.nix
index 149d8115054..e302ef51809 100644
--- a/pkgs/development/compilers/elm/default.nix
+++ b/pkgs/development/compilers/elm/default.nix
@@ -7,7 +7,7 @@ let
fetchElmDeps = pkgs.callPackage ./fetchElmDeps.nix { };
- hsPkgs = self: pkgs.haskellPackages.override {
+ hsPkgs = self: pkgs.haskell.packages.ghc8107.override {
overrides = self: super: with pkgs.haskell.lib.compose; with lib;
let elmPkgs = rec {
elm = overrideCabal (drv: { |
|
@sternenseemann no worries I can tackle that independently of the rest of the work. It will be more sane way to proceed with this anyway. You can skip elm for now I'll report the status back in here once I know more. |
|
I just released yarn2nix 0.10.1 https://hackage.haskell.org/package/yarn2nix which has support for aeson-2.0 (it’s been rebased onto this branch). |
Cheese in a package update while keeping the old expression in hackage-packages.nix, so we can avoid any regressions updating our hackage snapshot might introduce.
pkgs.taffybar stays working because taffybar is marked unbroken in configuration-ghc810x.nix
|
@rnhmjoj Seems like the |
|
@sternenseemann I tested Anyway, if the test failing is a problem you can replace 8.10 with 9.0.2 or remove the case altogether. |
|
@rnhmjoj A if it's not a regression, we can probably just drop the case. If I recall correctly, you didn't alter the 8.10 expression which would explain it? |
Oh, you're right. I would change the test case to use GHC 9.0.2, then. |
We should only make use of asserts to assert a property about the *current* attribute in order to make it possible for downstream users to change versions of packages: When a downstream user changes the package an attribute points to, the assert is removed as the attribute is swapped out, so asserting something about itself is okay. However, when it asserts a property about another package, changing that other package may break the package unexpectedly, with no better workaround then passing in an empty `configurationCommon` overlay. See also: #166425
|
Thank you, to everyone who contributed! This was much more work than we had expected. Enjoy your GHC 9.0 with all the updates! |
|
Great job @maralorn and @sternenseemann !! |
|
Hi, I just stumbled across this. I maintain the |
|
renaming the fix in #171438 |
fixes
```
error: querying available packages failed
caused by: nix-env failed with error: nix-env failed with exit code 1:
error: attribute 'streamly_0_8_1_1' missing
at /nix/store/lw6gp8rrhd7lpi81dk9wr1l09a7za523-source/pkgs/development/haskell-modules/configuration-darwin.nix:259:6:
258| ] ++ (drv.libraryFrameworkDepends or []);
259| }) super.streamly_0_8_1_1;
| ^
260|
```
PR NixOS#160733 didn't catch this it seems.
This Merge
This is not your usual
haskell-updatesrotation! We're bumping the default GHC by one major release.This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates. You may be able to find an up-to-date Hydra build report at cdepillabout/nix-haskell-updates-status.
Since this is quite a big change, cleaning up regressions and merging may take longer than usual.
haskellPackages Workflow Summary
Our workflow is currently described in
pkgs/development/haskell-modules/HACKING.md.The short version is this:
haskell-updates(normally at the beginning of a merge window).haskell-updatesintomasterevery two weeks.mergeablejob is succeeding on hydra.maintainedpackage is still broken at the time of merge, we will only merge if the maintainer has been pinged 7 days in advance. (If you care about a Haskell package, become a maintainer!)This is the follow-up to #160015. Come to #haskell:nixos.org if you have any questions.
Rough order of business:
hackage2nixconfigbroken.yamland see what has fixed itselfCloses #163329