-
Notifications
You must be signed in to change notification settings - Fork 215
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
Use hnix-0.7 #1695
Use hnix-0.7 #1695
Conversation
Why does Hydra complain about
…when we have a |
@sjakobi: I just pushed a change that should fix the The issue is that when using In this particular case, the issue was that
... so GHC 8.6 versions or older depend on So the issue wasn't that The way I fixed it for the change I pushed was to run: $ cabal2nix --compiler ghc-8.4 cabal://aeson > ./nix/aeson.nix ... which then caused If we were using a newer version of Nixpkgs there is a more reliable way to fix this problem, which is to use In general, this trick only works for packages that are older than the Nixpkgs revision you are using, so we'd need a Nixpkgs revision newer than, say, |
Many thanks for the fix and the explanation @Gabriel439! I'll take a closer look at the Those recent Nixpkgs features sound nice! I hope we can update our version of Nixpkgs once |
The latest
|
010ce25
to
edaedb8
Compare
Somehow that last commit fails to trigger a new job at https://hydra.dhall-lang.org/jobset/dhall-haskell/1695… |
@sjakobi: It's working on it. Nix has two main phases when building things:
The first phase takes longer when you make large changes at the Nix level (like disabling profiling for all Haskell packages), but on subsequent runs it will speed up again. |
Thanks for the explanation, @Gabriel439! :) Instantiation seems to have failed due to an OOM situation while compiling Does the build machine have unexpectedly little available memory for some reason? |
@sjakobi: It has 8 GB of memory. It's the $40 / month option here: https://www.linode.com/pricing/ Another thing you can do is disable profiling just for the aeson =
pkgsNew.haskell.lib.disableLibraryProfiling haskellPackagesOld.aeson; ... right below where Lines 120 to 124 in b675924
|
The …and so did the When there are multiple builds running at the same time, can they starve each other of memory?! |
@sjakobi: I think the newer evaluation had not yet kicked in, because once you reverted that change it should no longer be trying to rebuild Cabal. Indeed, |
Wow, I could have sworn that the error log was from today. This is so confusing! :( The new problem is that when building Disabling profiling for all reverse dependencies of Disabling it categorically sounds much better to me. So what can we do to make that Cabal re-build pass? I saw that |
Sorry for this endless back and forth with me being so clueless about Nix BTW. Can you recommend some resources that would help me get up to speed? |
@sjakobi: Are you able to run the Nix build locally yourself? Once you set that up you can iterate much more quickly than using CI In principle, all you need to reproduce what CI does is to run:
... and you can build specific top-level attributes by adding them as: $ nix build --file ./release.nix linux-dhall |
I think I had it working before, but last time I tried, I aborted the build as it just seemed to take forever.
I just tried this from a fresh nix install but got a test failure in a Python dependency:
The issue was reported in pyca/pyopenssl#791 and there's a merged fix for nixpkgs: NixOS/nixpkgs#46072. |
@sjakobi: Have you added |
@Gabriel439 My
But the caches don't really seem to help. There's still a lot of rebuilding going on and in the end I get the same failure as above. |
@sjakobi: What version of Nix are you currently using? To answer your original question, the relevant resource is the Nixpkgs manual: http://nixos.org/nixpkgs/manual/ I'm currently looking into this, but at the moment I'm not able to reproduce the mass rebuild you're seeing |
@sjakobi: There is also a short-term workaround that we can use to get around the build constraints of the CI machine, which is to build on a machine that has more resources available (e.g. either of our own development machines) and copy the built closure to |
|
@sjakobi: There's actually another potential workaround that may be more robust: drop support for GHC 8.0. This appears to be a problem that affects the older version of the compiler due to it being less efficient. Newer versions are building successfully. |
@Gabriel439 Oh, I had totally missed that the OOMs were with GHC 8.0! In that case let's indeed drop support for 8.0. Should we add CI for GHC 8.2 instead, or simply drop support for 8.2 too? (A local test-install indicates that 8.2 requires much less memory to build |
@sjakobi: Let's try replacing GHC 8.0 with GHC 8.2 and see if that works. If it's still a problem then we can try dropping it. |
So I managed to resolve my setup / caching issue by cleaning my nix install properly before starting afresh. But
What can I do about this? EDIT: This is on |
@sjakobi: I believe you need to add this to
|
dhall-nix/src/Dhall/Nix.hs
Outdated
@@ -208,13 +209,13 @@ Right x: y: x + y | |||
dhallToNix :: Expr s Void -> Either CompileError (Fix NExprF) | |||
dhallToNix e = loop (Dhall.Core.normalize e) | |||
where | |||
loop (Const _) = return (Fix (NSet [])) | |||
loop (Const _) = return (Fix (NSet NNonRecursive [])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So my understanding is that these empty sets are a bit like a default value for things that I can't translate. Should I make a name for this to avoid repetition? Something like
stub = Fix (NSet NNonRecursive [])
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, currently all types are translated to {}
in Nix. You can define a reusable term to reduce repetition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went with untranslatable
for the name.
@@ -218,7 +212,7 @@ let | |||
); | |||
}; | |||
|
|||
overlayGHC802 = pkgsNew: pkgsOld: { | |||
overlayGHC822 = pkgsNew: pkgsOld: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't actually checked whether the overlay is still necessary in this form. It doesn't seem to hurt though…
CI is finally green. Could you review @Gabriel439? Many thanks for all your help so far! :) |
... as pointed out by Gabriel in #1695 (comment).
dhall-nix/src/Dhall/Nix.hs
Outdated
@@ -208,13 +209,13 @@ Right x: y: x + y | |||
dhallToNix :: Expr s Void -> Either CompileError (Fix NExprF) | |||
dhallToNix e = loop (Dhall.Core.normalize e) | |||
where | |||
loop (Const _) = return (Fix (NSet [])) | |||
loop (Const _) = return (Fix (NSet NNonRecursive [])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, currently all types are translated to {}
in Nix. You can define a reusable term to reduce repetition
936080e
to
74e52b4
Compare
74e52b4
to
0ec0ea5
Compare
... as pointed out by Gabriel in #1695 (comment).
This time the compilation of I'll try again. |
Unfortunately Hydra caches the failure – it can't tell that the failure is due to the environment (unsufficient memory), not the code. How do I tell Nix not to build and run |
@sjakobi: In this section: https://github.com/dhall-lang/dhall-haskell/blob/sjakobi/hnix-0.7/nix/shared.nix#L222-L227 ... you can add: dhall = pkgsNew.haskell.lib.dontCheck haskellPackagesOld.dhall; |
This also removes support for GHC 8.0.2 in the Nix utilities, since recent aeson versions were OOM'ing in CI with 8.0.2. Instead we add support for GHC 8.2.2. This also remove the old and no longer used dhall-nix/.travis.yml.
2dc7e70
to
0183204
Compare
No description provided.