This adds a useful hook to be used for projects that use stestr,
it is primiative at the moment but covers most scenarios for using
it.
This PR also changes a Python module to start using it, once it
lands, follow up PRs can update all of them to use it tree-wide.
Signed-off-by: Vinetos <contact+git@vinetos.fr>
Prior to this change all python packages using `setuptools-rust` were broken when cross compiled as they built binaries for the build platform instead of for the host platform.
The setuptoolsRustBuildHook hook would have to be included as a native build input instead of the `setuptools-rust` package, but practically wasn't used anywhere.
This change makes it so that `setuptoolsRustBuildHook` becomes unnecessary, and instead `setuptools-rust` propagates a setup-hook directly setting up the build environment, similar to how cmake does it when included via nativeBuildInputs.
This change fixes cross on all packages using `setuptools-rust` as a build-system.
Wrap each elements of disabledTests with parenthesis
so that when __structuredAttrs = true,
people could use sub-expressions an element.
E.g.
```nix
{
disabledTests = [
"ClassFoo and test_foo"
"test_bar"
];
}
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 57b193d8dd
result/bin/apply-formatting $NIXPKGS_PATH
Use lib.overrideDerivation instead of <pkg>.overrideDerivation
to fix the evaluation of
python3Packages.pythonCatchConflictsHook.tests.catches-conflict-multiple-chains,
as buildPythonPackage and buildPythonApplication no longer provide
<pkg>.overrideDerivation
Clean up the leftover of commit 58bfe74123 ("buildPython*:
Deprecate and remove (buildPython* { ... }).override")
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.
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.
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.
This adds a test to ensure no new uses of `buildPythonApplication` can
be added to `python-packages.nix`.
Python packages can be grouped into two groups: 1) applications and 2)
packages providing importable modules. In `python-packages.nix` we only
want to have 2). 1) should be in the top-level package set.
To achieve this, all setup hooks need to be marked as being a setup hook.
For the setup hooks in the Python packages set this is done by creating
a new builder, `makePythonHook`.
Because there were issues with splicing, the file importing all the hooks
is converted to an extension. All non-packages were moved out of `python-packages.nix`
into `python-packages-base.nix`. The `keep` argument to `makeScopeWithSplicing
was cleaned up as well; there is no need to keep this one manually in sync
reducing the risk of breaking cross-compilation.
