Haskell: Added haskellPackages.shellFor #36393
Conversation
|
/cc @shlevy, I think you might be interested in this :) |
| 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.
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.
Yeah, this is the right way. Though I'd do input.outPath != p.outPath
ElvishJerricco
force-pushed
the
haskell-shell-for
branch
from
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-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)