-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
haskellPackages.ghc: 8.10.7 -> 9.0.2 #160733
Conversation
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-updates
rotation! 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-updates
intomaster
every two weeks.mergeable
job is succeeding on hydra.maintained
package 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:
hackage2nix
configbroken.yaml
and see what has fixed itselfCloses #163329