-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
srcOnly: fix invocation and document #85750
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
Conversation
The |
Previously, callPackage would try and fill the arguments such as `name` and `src` which would cause problems if those existed as top-level attributes. This also makes it clearer what part is the function signature. Then document the derivation inline in the code to explain the ellipsis and various use-cases.
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.
LGTM.
The
buildInputs
argument really should benativeBuildInputs
if the goal is to provide some extra unpackers.
This seems reasonable, and probably deserves a followup commit. I suspect it'll break some usage, but the ripple effect there causes nixpkgs improvement if anything.
@edef1c: pushed the nativeBuildInputs change. Inside of nixpkgs, |
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.
This looks good to me.
Thanks for adding documentation!
The only reason to pass build inputs is to extend the unpackPhase with custom unpack commands. Eg: add "unrar" to unpack rar sources. And those should really be passed as native build inputs. Why? Because nativeBuildInputs is for dependencies that are used at build time but will not propagate as runtime dependencies. And also, cross-compilation.
fixed the evaluation and made the last commit backward-compatible |
Motivation for this change
Previously, callPackage would try and fill the arguments such as
name
and
src
which would cause problems if those existed as top-levelattributes. This also makes it clearer what part is the function
signature.
Then document the derivation inline in the code to explain the ellipsis
and various use-cases.
This is a follow-up on #80903
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)