Always specify the postPhases attribute as a list instead of a string.
Append elements to the postPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Always specify the preDistPhases attribute as a list instead of a string.
Append elements to the preDistPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Handle element insertion before a specific element using string
substitution as before, but handle both structured and unstructured
attributes.
Always specify the preInstallPhases attribute as a list instead of a
string.
Append elements to the preInstallPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Add a test where a conflicting package can be found at the end of
multiple dependency chains. This is far too simple an example to
demonstrate the ill effects of exponential time complexity, but does
serve to demonstrate how the error output changes when each path is only
visited once.
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.
Yueh-Shun Li