Python always uses "gnu" prefixed ABI names, and this patch handles this by
doing a musl->gnu string replacement.
With pkgsCross.armv7l-hf-multiplatform.pkgsStatic, the previous name was:
_sysconfigdata__linux_arm-linux-gnu
Now, the corrected name is:
_sysconfigdata__linux_arm-linux-gnueabihf
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's switch to attrset-passing form, to provide some minimal level
of sanity-checking.
`lib.extends hooks pythonPackagesFun` includes python which we want to
splice
what this fixes:
```
nix-repl> lib.elemAt pkgsCross.aarch64-multiplatform.python3Packages.xpybutil.nativeBuildInputs 0
«derivation /nix/store/39dkb51rciw6zwg0c2c44gpmpjapddxc-python3-aarch64-unknown-linux-gnu-3.10.12.drv»
```
to
```
nix-repl> lib.elemAt pkgsCross.aarch64-multiplatform.python3Packages.xpybutil.nativeBuildInputs 0
«derivation /nix/store/21ldw2dp26xvv9iyxn9x77a8yh4waqz5-python3-3.10.12.drv»
```
Before https://github.com/NixOS/nixpkgs/pull/194205 The keep python used to work by accident because self was passed from
__splicedPackages https://github.com/NixOS/nixpkgs/pull/196052/files#diff-44ce3495c4f983ce64dd47c86a9d3e77bad210b2709c098a3806998dcd9b000bR213
But now it does not work because overrideAttrs is used on python in
python-packages-base.nix
Preferably we would [ splice the hooks too ](https://github.com/NixOS/nixpkgs/pull/228139) but we cannot do that until [Package sets within derivations (i.e. python3.pkgs) are not spliced](https://github.com/NixOS/nixpkgs/issues/211340) is fixed, because people often use `python3.pkgs.wrapPython` in `nativeBuildInputs` (it's correct but python3.pkgs should be python3Packages to get splicing.
The setuptools-rust requires some environment variables to really
perform cross build, otherwise it just builds for build platform.
This adds setup hook that introduces these environment variables.
There are three variables.
The PYO3_CROSS_LIB_DIR has to point to the target's Python library
directory. This has to be directory for the target not for the build or
host. We have to choose the correct target Python. I am unsure how to do
that simply in nixpkgs and this this implementations just delays this
and waits for the correct Python when package using this hook is build.
The CARGO_BUILD_TARGET triggers cross compilation in setuptools-rust.
This is simply the Rust target specification.
The CARGO_TARGET_*_LINKER variable should not be essentially required
but setuptools-rust probably mangles the Rust build environment somewhat
and that results to the missing linker. By explicitly specifying it
using the environment variable we force the correct linker.
Since python documentation requires Sphinx to build, documentation is built in
separate derivation to avoid hard recursion/bootstrapping questions and plugged
into main derivation. Care is taken that "python3.doc" derivation feels and
looks as close as possible to as if it were main derivation were multi-output
one.
This change does not cause rebuild of python3 itself.
Add a marker file to the python outputs that tells pip and other tooling
following PEP 668 that they should not be installing things system-wide.
This provides better feedback to the user and also potentially avoids issues in
single-user installs where the /nix/store is owned by the user.
For more details, see <https://peps.python.org/pep-0668/>
Here is how it currently looks like:
$ pip install requests
error: externally-managed-environment
× This environment is externally managed
╰─> This command has been disabled as it tries to modify the immutable
`/nix/store` filesystem.
To use Python with Nix and nixpkgs, have a look at the online documentation:
<https://nixos.org/manual/nixpkgs/stable/#python>.
mkPythonDerivation: apply checks to buildInputs as well
fixup: add a suggestion about nativeBuildInputs
Clean up the wording, add reasons for the suggestions
switch to throw
Adjust error to clarify build-time vs. run-time
