Add
meta.problems.buildPythonPackage-internal-disabled-overridePythonAttrs
when <pkg>.overridePythonAttrs taking deprecated argument disabled.
buildPythonPackage and buildPythonApplication
still takes argument disabled,
transformed with makeOverridablePythonPackages.
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Transparently convert the { disabled = true; } to
meta.problems.unsupportedPython
and remove the `disabled` argument,
such that <pkg>.overridePythonAttrs can always
mitigate unsupportedPython by removing it from meta.problems
Co-authored-by: Eman Resu <ellakalle6@gmail.com>
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Remove overrideStdenvCompat from python-packages-base.nix
Add meta.problems.buildPythonPackage-internal-stdenv
when getting the stdenv argument
to make it an package evaluation error.
Add a test case in tests.overriding
(overridePythonAttrs-deprecated-arg-stdenv)
asserting that the problem appears when overriding with
<pkg>overridePythonAttrs with the deprecated stdenv argument.
If Nix supports lazy attribute names in the future,
this change will make `<python package>.override` warning-free
and make such warning (or future throw) remediateable
via another override.
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>
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.
