treewide: use overlays to pass a custom stdenv to buildPythonPackage / bulidPythonApplication#476401
Conversation
59d97f6 to
6f3fa6b
Compare
|
If anyone has a better idea than to drop the overriding tests, I'm happy for that. |
|
I evaled nixpkgs locally with you may want to do something similar. Otherwise it's almost impossible to find the failures. |
|
I had thought it would only be triggered after Nixpkgs 26.05 branch-off. Sorry for causing the trouble. |
The test is meant to be removed aftre tree-wide migration. |
6f3fa6b to
a7ac8bc
Compare
|
Let's merge after updating the Thank you for fixing them! |
Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
a7ac8bc to
78cb6cb
Compare
There was a problem hiding this comment.
I had thought it would only be triggered after Nixpkgs 26.05 branch-off.
The "oldest supported release" gets bumped when the previous oldest supported release goes from "deprecated" to "unmaintained". It's not directly linked to branch-off; it usually happens a month or two after branch-off, IIUC.
I.e., 25.11 becomes the "oldest supported" at some point during the 26.05 cycle.
Sorry for causing the trouble.
We would've had to deal with this eventually, so no need to be sorry.
Thanks @leona-ya for handling it!
I evaled nixpkgs locally with [...] you may want to do something similar. Otherwise it's almost impossible to find the failures.
Good idea. It'd need to allow for pname being missing, but I agree it makes the error much more useful.
| overridePythonAttrs-stdenv-deprecated = { | ||
| expr = | ||
| (package-stub.overridePythonAttrs (_: { | ||
| stdenv = pkgs.clangStdenv; | ||
| })).stdenv; | ||
| expected = pkgs.clangStdenv; | ||
| }; | ||
| overridePythonAttrs-override-clangStdenv-deprecated-nested = { | ||
| expr = | ||
| (package-stub-gcc.overridePythonAttrs { | ||
| stdenv = pkgs.clangStdenv; | ||
| }).stdenv; | ||
| expected = pkgs.clangStdenv; | ||
| }; |
There was a problem hiding this comment.
Ideally, I'd like to have a test that asserts the override still works and asserts the warning is printed. I don't think that's possible with the current overriding.nix.
I think we'd need to come up with something that evaluates test cases within a test derivation (similar to CI's eval or lib's lib/tests/test-with-nix.nix and ), that way we can capture the eval's stderr and make assertions on its content.
This is too complex to be in scope for this PR, and maybe too complex to be worth it for these two test cases. But maybe it'd be useful to have a way to implement more complex pkgs tests, like we already have for lib tests?
There was a problem hiding this comment.
I also don't really know a way how this would be done easily. Also yes, probably out of scope here.
There was a problem hiding this comment.
Agreed. If #477208 or another PR has a solution, it can revert this commit or introduce a new equivalent test. I don't want to block this PR by waiting for a solution.
Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…th an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…PythonApplication Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`. Passing the normal `stdenv` to `buildPythonApplication` doensn't do anything.
…ythonApplication Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`. Passing the normal `stdenv` to `buildPythonApplication` doensn't do anything.
… buildPythonApplication Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`. Passing `python.stdenv` to `buildPythonApplication` doensn't do anything
…ion with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
f23c65d to
f53ddbe
Compare
…tion with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…on with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…th an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…th an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…plication with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…on with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
…n with an override Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated with `oldestSupportedRelease = 2511`.
These tests now throw a warning which is prohibited inside Nixpkgs:
Passing `stdenv` directly to `buildPythonPackage` or `buildPythonApplication` is deprecated. You should use their `.override` function instead, e.g:
buildPythonPackage.override { stdenv = customStdenv; } { }
f53ddbe to
9667e93
Compare
MattSturgeon
left a comment
There was a problem hiding this comment.
The only "changed" package is the test and the diff LGTM. Let's merge to unblock #476384
Thanks!
|
Successfully created backport PR for |
Bumping
oldestSupportedReleaseto2511failed because of multipleThis PR either uses this approach or just removes superfluous
stdenvdeclarations.Required for #476384
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.