buildPython*: extend overrideStdenvCompat to fixed-point arguments#477208
Conversation
45313a0 to
2543891
Compare
MattSturgeon
left a comment
There was a problem hiding this comment.
I commented commit-by-commit, and the GitHub review summary seems very confused. Hopefully this posts everything ok... 🤞🏻
2543891 to
c2d8b10
Compare
c2d8b10 to
a4a7c43
Compare
a4a7c43 to
31c9079
Compare
MattSturgeon
left a comment
There was a problem hiding this comment.
I tested this locally against #477760, and tests.eval built successfully. Admittedly, the test coverage for stdenv overrides isn't extensive, but it does provide a sanity check 😁
ea064b0 to
22453e0
Compare
d635ffa to
9cc99be
Compare
26bc9f8 to
7304784
Compare
Co-authored-by: Matt Sturgeon <[email protected]>
… override value If Nix supports lazy attribute names in the future, this change will make `<python package>.override` warning-free and make such warning (or future throw) remediateable via another override.
with `passthru.__stdenvPythonCompat` Co-authored-by: Matt Sturgeon <[email protected]>
7304784 to
de48b6a
Compare
MattSturgeon
left a comment
There was a problem hiding this comment.
LGTM. Thanks! I think I'll merge this to avoid further delays.
There was a problem hiding this comment.
The error message mentions buildPythonPackage and buildPythonApplication, but it also catches passing stdenv to overridePythonAttrs.
Ideally, we'd make this a smart warning that knows which function the user was using to incorrectly supply stdenv. I can't think of a sane way to handle that though.
I'm not suggesting we reword the warning to mention all three funtions, as that would quickly get rather verbose. I think this is out-of-scope for this PR anyway, as I think overrideStdenvCompat already handled overridePythonAttrs?
There was a problem hiding this comment.
How about adding position information?
There was a problem hiding this comment.
Would this benefit from a comment explaining why we add __stdenvPythonCompat (i.e. for overrideStdenvCompat), mentioning that it is internal, reminding us to remove when dropping overrideStdenvCompat, etc?
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-25.11
git worktree add -d .worktree/backport-477208-to-release-25.11 origin/release-25.11
cd .worktree/backport-477208-to-release-25.11
git switch --create backport-477208-to-release-25.11
git cherry-pick -x 4ef0c2ded41c446cd8cd2611554487363e28ee15 5b114f0534d820d60186d402e8964b64d67e810e de48b6a845e7f206d8c11075a507814b6b5d13c7 |
Description
Implementation
stdenvargument aspassthru.__stdenvPythonCompatwhen specified.passthru.__stdenvPythonCompat(instead of insideoverrideStdenvCompat).overrideStdenvCompatinpython-packages-base.nix, construct a Python package with overriddenstdenvif<python pkg>.__stdenvPythonCompatexists.handleMsgStdenvArgto<python pkg>.overrideto pass the message handling function (ignoreing, warning, throwing, etc.), with a comment about its being an implementation detail.tests.overriding'soverridePythonAttrs-stdenv-deprecatedignore the deprecation warning withhandleMsgStdenvArg.Effect
python3Packages.buildPythonPackage's deprecatedstdenvargument to the situation whenbuildPythonPackagetakes fixed-point arguments, applying @MattSturgeon's suggestion in PR comment buildPython*: support fixed-point arguments #271387 (comment)overrideSdenvCompatwork with fixed-point arguments, giving us the freedom to decide whether to allowoverridePythonAttrsto take extension-style update arguments (finalAttrs: previousPythonAttrs: { ... }) (issue Python:overridePythonAttrsshould supportfinal: prev:style overrides #258246 )overrideStdenvCompatwith tests even after warnings take effect, addressing @leona-ya and @MattSturgeon's PR comments treewide: use overlays to pass a custom stdenv to buildPythonPackage / bulidPythonApplication #476401 (comment) and treewide: use overlays to pass a custom stdenv to buildPythonPackage / bulidPythonApplication #476401 (comment)Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.