The underlying `mk-python-derivation.nix` functions do not have `stdenv`
in their functionArgs, so it was redundant to explicitly remove it.
(cherry picked from commit 9d87f178ed)
Make it possible to mix overridePythonAttrs and overrideAttrs, i.e.
((<pkg>.overrideAttrs (_: { foo = "a"; })).overridePythonAttrs (_: { })).foo now works
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
(cherry picked from commit ca6c090082)
Attach overridePythonAttrs by attribute set update
instead of `stdenv.mkDerivation`'s `passthru`.
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
(cherry picked from commit e8302431ef)
To be able to splice, we can't fail to eval before returning an
attribute set. By checking for f ? override, we need to force f which
isn't always possible, whereas mirrorFunctionArgs serves as an
indirection which wraps the inner thunks in an attribute set that can
always be returned. Fortunately, there should be no case when f
evaluates successfully and does not have the override attribute, so we
can just remove the condition.
This fixes evaluation of buildPython* based packages in certain splicing
situations by being lazier. An example of this is
pkgsCross.ghcjs.buildPackages.nixpkgs-openjdk-updater on staging right
now (ff5098e).
On Nixpkgs >= 26.05 (or precisely, oldest supported release >= 25.11),
warn about the use of buildPython*'s deprecated argument `stdenv`.
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Fix `makeOverridablePythonPackage` in python-package-base.nix
and unshadow `buildPython*.override`.
This makes it possible to override the dependencies of buildPython*.
E.g., `buildPythonPackage.override { unzip = unzip-custom; }`
returns a derived version of `buildPythonPackage` with
the `unzip` package overridden with `unzip-custom`.
This doesn't seem to be necessary anymore. I confirmed by:
- Adding a lib.warn into the __attrsFailsEvaluation branch - never got
any.
- Removing it everywhere and running full Eval on it - no errors, no
rebuilds.
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
Deprecate (buildPythonPackage { ... }).override for Python packages in
favour of overridePythonAttrs.
This change does not affect the override interface of most Python
packages, as the override interface is provided by callPackage and
shadows the locally defined override attribute.
This function is not, and never have been, used anywhere inside nixpkgs, outside of bootstrapping setupcfg2nix itself.
It was added in https://github.com/NixOS/nixpkgs/pull/38778 by @shlevy.
It has no out-of-tree users on Github either. External breakage is not expected.
As we continue iterating on Python infrastructure for Python 3, some
code is starting to diverge for Python 2. If we copy the current state
of mk-python-derivation.nix and freeze it for Python 2, we can iterate
on it for Python 3 with more freedom.
fetchPypi doesn't use python under the hood and doesn't need to be tied
to a specific version of python. Moving it to top level makes it more
consistent with other fetchers and makes code generation easier.
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.
