buildPython*: bring back buildPython*.override#366593
buildPython*: bring back buildPython*.override#366593ShamrockLee merged 1 commit intoNixOS:masterfrom
Conversation
|
e7aa58a to
c8b0f1d
Compare
|
Rebased the feature branch on top of |
c8b0f1d to
442514d
Compare
|
Bump onto |
442514d to
0d01e8b
Compare
|
Bump. |
MattSturgeon
left a comment
There was a problem hiding this comment.
This is useful and will unblock #271762 (which itself is blocking fixed-point args in buildPythonPackage and buildPythonApplication).
I've tested locally in the repl that buildPythonPackage.override behaves as expected.
As this is such a trivial patch - and no one has complained in the 10 months it's been open - I plan to merge soon, assuming there is no further feedback. Or I support a self-merge by @ShamrockLee if they prefer.
Fix `makeOverridablePythonPackage` in python-package-base.nix
and unshadow `buildPython*.override`.
This makes it possible to override the dependencies of buildPython*.
E.g., `buildPythonPackage.override { unzip = unzip-custom; }`
returns a derived version of `buildPythonPackage` with
the `unzip` package overridden with `unzip-custom`.
0d01e8b to
cce0f3f
Compare
|
The Linting GitHub action complains Update: Cleared after rerunning the failed test and dependent tests. |
|
Successfully created backport PR for |
|
Adding the backport label back; I think it's important that the python build helpers remain in sync across all supported releases. Otherwise, we can't backport changes to any package that depends on a |
|
This change, together with another change only present on staging, causes evaluation of |
Have you bisected the staging change? |
|
No, otherwise I'd have noted it here. Others have claimed to be able to reproduce the issue on master as well, though I was not able to replicate that since I do not know a specific revision. |
|
I bisected using
However, the very first commit of #271762, which this PR unblocked, fixes the eval issue again and was merged soon after.
I don't think staging is relevant ? |
|
Sorry for causing the trouble.
The first commit of PR #271762 moves I.e., Before: nonoverridableBuildPythonPackage {
passthru = {
overridePythonAttrs = <the overrider>;
};
}After: nonoverridableBuildPythonPackage {
passthru = { };
}
// {
overridePythonAttrs = <the overrider>;
} |
|
Could we construct a simplified reproducer for the evaluation error based on the merged commit of this PR? This would be a great opportunity to add an overriding test. |
Like packages, build helpers returned by
callPackagehave their ownoverridethat can produce a customized version of them with specific dependencies overridden. However, the current implementation ofmakeOverridablePythonPackage(the function that adds.overridePythonAttrsto the packagesbuildPython*returns) doesn't consider such<function>.overrideattribute, causingbuildPython*.overrideto get lost.This PR fixes
makeOverridablePythonPackageand unshadowsbuildPython*.override, making it possible to override the dependencies of buildPython*. E.g.,buildPythonPackage.override { unzip = unzip-custom; }returns a derived version ofbuildPythonPackagewith theunzippackage overridden withunzip-custom. Such overriding approaches can already be found in Nixpkgs. -- the implementation offetchFromGitHubusesfetchzip.override { withUnzip = false; }to obtain a custom version offetchzipwithoutunzip-related dependencies inside its returning derivation.This is a much simplified and less controversial version of #271762.
This PR causes no rebuild and is fully backward compatible.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.