In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
The way we build python environments is subtly broken. A python
environment should be semantically identical to a vanilla Python
installation in, say, /usr/local. The current implementation, however,
differs in two important ways. The first is that it's impossible to use
python packages from the environment in python virtual environments. The
second is that the nix-generated environment appears to be a venv, but
it's not.
This commit changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We remove the sitecustomize.py file from the base python package.
This file was used tweak the python configuration after it was
incorrectly initialized. That's no longer necessary.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
When PyPy introduced Python 3.8 support with version 7.3.6, they also
migrated to using CPython's directory layout [0]:
> The 3.8 package now uses the same layout as CPython, and many of the
PyPy-specific changes to `sysconfig`, `distutils.sysconfig`, and
`distutils.commands.install.py` have been removed. The stdlib now is
located in `<base>/lib/pypy3.8` on `posix` systems...
When we upgraded past this version and added Python 3.8 support [1], the
`sitePackages` value was never updated, leading `bootstrapped-pip` to fail
to build, because wheel was trying to be located in `$out/site-packages`,
when it was actually installed to `$out/lib/pypy3.8/site-packages`.
[0]: https://www.pypy.org/posts/2021/10/pypy-v736-release.html
[1]: eec28b8cfd
- Remove code related to i686 archs (not supported anymore since #209100)
- Split non-install steps in installPhase in installCheckPhase/preFixup
- Add missing pre/post hooks
Also build it with pythonInterpreters.pypy27_prebuilt instead of
python27, to avoid it being broken after #201859 is merged.
Keep in mind that the above change will make this derivation only work
with x86_64-linux for now (since pypy27_prebuilt is only packaged for
that platform). However support for newer platforms can be added later,
and a working package for one platform is better than a broken package
in 4 platforms.
Python package sets can be overridden by overriding an interpreter
and passing in `packageOverrides = self: super: {...};`. This is fine
in case you need a single interpreter, however, it does not help you
when you want to override all sets.
With this change it is possible to override all sets at once by
appending a list of "extensions" to `pythonPackagesExtensions`.
From reading the implementation you might wonder why a list is used, and
not
`lib.composeExtensions`? The reason is the latter requires knowledge of
the library function. This approach should be easier for most users
as it is similar to how we append to lists of e.g. inputs or patches
when overriding a derivation.
they ship their own openssl
as of this commit, that is actually openssl 1.1.1m, the same version we have in openssl_1_1
maybe the package should still be marked as vulnerable, because they ship their own openssl
The implementation of multiprocessing.cpu_count() tries to call the
impure sysctl binary. In the sandbox that fails, so cffi bindings are
not generated.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
As part of the splicing the build/host/target combinations of the interpreter
need to be passed around internally. The chosen names were not very clear,
implying they were package sets whereas actually there were derivations.
