-
-
Notifications
You must be signed in to change notification settings - Fork 15.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
Haskell: Added haskellPackages.shellFor #36393
Conversation
/cc @shlevy, I think you might be interested in this :) |
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.
🎆
packageInputs = builtins.map (p: p.override { mkDerivation = haskellLib.extractBuildInputs p.compiler; }) selected; | ||
haskellInputs = | ||
builtins.filter | ||
(input: pkgs.lib.all (p: builtins.toString input != builtins.toString p) selected) |
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.
Is this an ok way of comparing two packages for equality? I thought comparing on pname
would be too ad-hoc and error prone.
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, this is the right way. Though I'd do input.outPath != p.outPath
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.
Changed
a9e944d
to
9adb4d2
Compare
@shlevy Is it too late to get this into 18.03? |
@ElvishJerricco That's up to @vcunat and @fpletz |
|
@Ericson2314 I don't have anything quite like this... But yeah, agreed about point 3. |
@shlevy there'd be a real nifty way with poisoned derivations to do that :D. |
@Ericson2314 I think it would suffice to simply leave a warning about that case. But a more comprehensive solution would be nice :) I just wouldn't want certain packages to be not built without the user having any idea why, so I think I'd rather see that case become an error than have it handled implicitly. |
@ElvishJerricco I'd do a warning, but this shouldn't be an errror. It's quite normal to fork a dependency that your other dependencies also depend on. |
In 18.03 since b8ebbc0. Adding new functions seems safe to me 👍 |
Motivation for this change
Building multi-package projects is pretty common, and nixpkgs currently doesn't provide a standard way to work on them simultaneously with an incremental tool like cabal new-build. This function achieves that by extracting your packages' build inputs and making a shell with those available.
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)