Broken since the switch to PyPA's build/installer in
6c85fff302.
The hook was always janky and maintainers appear to not want its current
implementation in-tree. No replacement is currently planned.
However, this leaves the path open for future replacements as a broken
hook will no longer be installed by default.
Prevent the hook from erroring out on missing specifiers, as reported for
`highspy`, which currently ships with a pre-release version, triggering
the following error message:
- highspy not satisfied by version 1.7.1.dev1
Is it PyOpenSSL or pyOpenSSL or pyopenssl? With this change you don't
have to care. Write it as pYoPeNSsL for all I care¹.
Can we do it like that? Yes, we can. Distribution names should be matched
with `re.IGNORECASE` according to the wheel specification².
[1] https://packaging.python.org/en/latest/specifications/core-metadata/#name
[2] Just kidding, please make it look sane.
Implements a hook, that checks whether all dependencies, as specified by
the wheel manifest, are present in the current environment.
Complains about missing packages, as well as version specifier
mismatches.
f292ef4 introduced a check for the Python version but uses `.version`,
which isn't friendly to other Pythons like PyPy which use versions
strings like 7.3, failing the >=3.10 check.
Using `.pythonVersion` fixes this check.
Co-authored-by: Pierre Bourdon <delroth@gmail.com>
By restoring and diverting to the old version.
Previously the newer language features and use of more modern stdlib
imports broke the hook on Python<3.10.
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
To escape the pkg_resources API deprecation:
> catch-conflicts.py:1: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
Also remove exceptions for the previus bootstrap packages.
This modifies the pypaBuildHook to not propagate its own python dependencies into the build environment. This prevents package conflicts.
- modify pypa-build-hook.sh to call pyproject-build via an absolute path. This removes the need of putting the dependencies inside the hook's propagatedBuildInputs
- remove the hook's dependencies from propagatedBuildInputs
- add a passthru test to the hook testing for the fix
The usage of wheel should be restricted to the hook. I discovered this
when trying to remove wheel from the Python bootstrap. Some packages
that needed wheel did not need it added explicitly because they use this
hook. This implicit change to the dependency tree shouldn't happen (even
though it is mostly harmless).
Upstream's recommended "python -m build" way of invoking build fails
when the working directory contains a file named "build.py". This is
common for poetry projects that build C extensions.
Since the wheel file name is based on the package metadata instead of
what we set in the derivation, if you set the version as `unstable-YYYYMMDD`,
for example, the hook would silently fail. We will ignore the version
now and just use a glob instead to match anything that has the package
name in its path.
Fixes#248185.
This reverts commit 2ffca30cde.
`793cc9d982415b71cdba729cf779bfc49e9d2ae7` `python3: splice python within python3Packages.callPackage`
Was reverted because it broke
`pkgsCross.aarch64-multiplatform.python3Packages.cryptography`
But by reverting the revert `pkgsCross.aarch64-multiplatform.python3Packages.cryptography` still builds.
I tried reverting the 2 cryptography update commits, and it still
worked, so I do not know why this would work now.
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.
When installing many python packages, a `direct_url.json` file appeared in the lib directory. Example:
```sh
➤ nix build nixpkgs/29755fec55e58a315b517d431b2be261772f2b80#python3Packages.flask
➤ cat result/lib/python3.10/site-packages/Flask-2.2.3.dist-info/direct_url.json
{"archive_info": {}, "url": "file:///build/Flask-2.2.3/dist/Flask-2.2.3-py3-none-any.whl"}⏎
```
As you can see, that file contains a wrong reference to `/build`.
In https://discuss.python.org/t/pep-610-usage-guidelines-for-linux-distributions/4012/4 there's an explanation on how to avoid this. Here, I'm implementing that change for nixpkgs.
@moduon MT-1075
Include full $name of the derivation into docdir, so documentation for
python package "foo" is installed into $out/share/doc/python3.10-foo-1.2.3
instead of just $out/share/doc/foo, where it may conflict with some
other package named "foo" and not-coinstallable with different
versions of the same python package.
Change from $name to $pname was introduced in [1ee5fca], probably as
unindented side-effect of adding support for formats other than html.
