python: Splice packages to better support cross#104201
python: Splice packages to better support cross#104201Ericson2314 merged 3 commits intoNixOS:masterfrom
Conversation
8a3bb2d to
8b69381
Compare
It's ugly as hell, but I suppose it is needed to codify how to make spliced package sets.
0b535e8 to
51f6805
Compare
There was a problem hiding this comment.
If we don't have the current legacy, how would the interpreter + package set could look then. Like Haskell? E.g., create the package set directly, instead of via the interpreter Would that solve any issues? It should make overriding easier I think, because you no longer need to bother with self.
The same fix as for PyPy should be done for Graal.
Do you mean what bigger changes might we do in addition, like making
I'm not sure what you mean. I do think the
Graal the JVM thing? Shouldn't we do that in a separate PR?
Yes that sounds reasonable. But I think rather land this and then try a few other |
Yes. The whole overriding is often considered confusing (it is) and different across package sets. If we're making changes that are (potentially) backwards-compatible, we should try to implement what we really want.
It uses the same
Okay. See also for Qt #102168. |
|
This makes sense as these are tools we want to run at build time.
Now non-`buildInputs` that are python packages should be resolved correctly.
51f6805 to
b57c5d4
Compare
Well I think this change is pretty much backwards compatible? If we were to change things everywhere to be consistent (which I do want to do) that would be a bunch more reviewers and things. OK with doing that as a follow-up?
Oh oops, I only did the fix for that with python 2. Sorry, fixed now. |
super was incorrectly possible until #104201 got merged.
Follow-up to NixOS#104201, related to NixOS#105113.
super was incorrectly possible until NixOS#104201 got merged.
The package set is an attribute of the interpreter. The function to
build an environment (`buildEnv`/`withPackages`) is part of the
interpreter. The interpreter is passed to itself, and needs to be
updated when overridden.
For cross-compilation we splice the package set, and for that the
various `build/host` interpreters and sets need to be available. We
select these currently through `pkgs.${pythonAttr}`. The `pythonAttr`
attribute was not fixed for `pythonFull`.
NixOS/rfcs#83
NixOS#104201
We need a better solution for this because this is very brittle.
The package set is an attribute of the interpreter. The function to
build an environment (`buildEnv`/`withPackages`) is part of the
interpreter. The interpreter is passed to itself, and needs to be
updated when overridden.
For cross-compilation we splice the package set, and for that the
various `build/host` interpreters and sets need to be available. We
select these currently through `pkgs.${pythonAttr}`. The `pythonAttr`
attribute was not fixed for `pythonFull`.
NixOS/rfcs#83
#104201
We need a better solution for this because this is very brittle.
as far as i can see there should be no reason to not splice the hooks
wrapPython for some reason has to be not spliced because 'substitutions.pythonHost = python;' causes
```
error: output '/nix/store/li07bad6s9brxx7cf8j408631nca39ka-python3.10-chardet-5.1.0-aarch64-unknown-linux-gnu' is not allowed to refer to the following paths:
/nix/store/fdqpyj613dr0v1l1lrzqhzay7sk4xg87-python3-3.10.10
```
ericson said in NixOS#104201 (comment) that the reason they were in keep was to not splice them but before the commit which broke hook splicing (33d12e5) everything appeared to be working correctly when cross-compiling
we also somehow get a correctly spliced python in nativeBuildInputs for free
Motivation for this change
Fixes #104135. Also should hopefully make it easier to fix these sorts of things later.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)CC @globin @FRidh @expipiplus1