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

Merged
merged 1 commit into from Mar 7, 2018

Conversation

Projects
None yet
6 participants
@ElvishJerricco
Copy link
Contributor

ElvishJerricco commented Mar 6, 2018

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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@ElvishJerricco ElvishJerricco requested a review from peti as a code owner Mar 6, 2018

@ElvishJerricco

This comment has been minimized.

Copy link
Contributor Author

ElvishJerricco commented Mar 6, 2018

/cc @shlevy, I think you might be interested in this :)

@shlevy

shlevy approved these changes Mar 6, 2018

Copy link
Member

shlevy left a comment

🎆

pkgs/development/haskell-modules/make-package-set.nix Outdated
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)

This comment has been minimized.

@ElvishJerricco

ElvishJerricco Mar 6, 2018

Author Contributor

Is this an ok way of comparing two packages for equality? I thought comparing on pname would be too ad-hoc and error prone.

This comment has been minimized.

@shlevy

shlevy Mar 6, 2018

Member

Yeah, this is the right way. Though I'd do input.outPath != p.outPath

This comment has been minimized.

@ElvishJerricco

ElvishJerricco Mar 6, 2018

Author Contributor

Changed

@ElvishJerricco ElvishJerricco force-pushed the ElvishJerricco:haskell-shell-for branch to 9adb4d2 Mar 6, 2018

@peti peti merged commit df6e6d9 into NixOS:master Mar 7, 2018

8 checks passed

grahamcofborg-eval ^.^!
Details
grahamcofborg-eval-check-meta config.nix: checkMeta = true
Details
grahamcofborg-eval-nixos-manual nix-instantiate ./nixos/release.nix -A manual
Details
grahamcofborg-eval-nixos-options nix-instantiate ./nixos/release.nix -A options
Details
grahamcofborg-eval-nixpkgs-manual nix-instantiate ./pkgs/top-level/release.nix -A manual
Details
grahamcofborg-eval-nixpkgs-tarball nix-instantiate ./pkgs/top-level/release.nix -A tarball
Details
grahamcofborg-eval-nixpkgs-unstable-jobset nix-instantiate ./pkgs/top-level/release.nix -A unstable
Details
grahamcofborg-eval-package-list nix-env -qa --json --file .
Details
@ElvishJerricco

This comment has been minimized.

Copy link
Contributor Author

ElvishJerricco commented Mar 7, 2018

@shlevy Is it too late to get this into 18.03?

@shlevy

This comment has been minimized.

Copy link
Member

shlevy commented Mar 7, 2018

@ElvishJerricco That's up to @vcunat and @fpletz

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Mar 8, 2018

  1. The is a super useful thing to have, thanks @ElvishJerricco!

  2. @shlevy I thought you already wrote something like this?

  3. I'm worried about correctness. If the list is [ p1 p2 ..], and p1 depends on a (not in the list) which depends on p2, then a shouldn't be built either.

@shlevy

This comment has been minimized.

Copy link
Member

shlevy commented Mar 8, 2018

@Ericson2314 I don't have anything quite like this... But yeah, agreed about point 3.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Mar 9, 2018

@shlevy there'd be a real nifty way with poisoned derivations to do that :D.

@ElvishJerricco

This comment has been minimized.

Copy link
Contributor Author

ElvishJerricco commented Mar 9, 2018

@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.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Mar 9, 2018

@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.

@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Mar 12, 2018

In 18.03 since b8ebbc0. Adding new functions seems safe to me 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment