| Age | Commit message (Collapse) | Author |
|
There is no need to disable Python packages for Python versions that are
no longer in Nixpkgs.
This change was generated using the following script:
pattern='^\s*disabled\s*=\s*pythonOlder\s*"3\.\([0-9]\|10\)"\s*;\s*$'
for f in $(find -name '*.nix'); do
grep -q "$pattern" "$f" || continue
sed -i "/$pattern/d" "$f"
if [ $(grep -c pythonOlder "$f") == 1 ]; then
sed -i '/^\s*pythonOlder,\s*$/d' "$f"
fi
nixfmt "$f"
done
|
|
|
|
|
|
If a Python package does not come with either `format` or `pyproject` we
consider it a setuptools build, that calls `setup.py` directly, which is
deprecated.
This change, as a first step, migrates a large chunk of these packages to
set setuptools as their explicit format
This is so we can unify the problem space for the next step of the
migration.
|
|
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 https://github.com/infinisil/treewide-nixpkgs-reformat-script/archive/a08b3a4d199c6124ac5b36a889d9099b4383463f.tar.gz \
--argstr baseRev b32a0943687d2a5094a6d92f25a4b6e16a76b5b7
result/bin/apply-formatting $NIXPKGS_PATH
|
|
|
|
E.g. when the Nix is changed
|
|
This commit reverts all python changes from 234bb31f611f43f8b744b305ab82035de637aaca.
|
|
The way we build python environments is subtly broken. A python
environment should be semantically identical to a vanilla Python
installation in, say, /usr/local. The current implementation, however,
differs in two important ways. The first is that it's impossible to use
python packages from the environment in python virtual environments. The
second is that the nix-generated environment appears to be a venv, but
it's not.
This commit changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We remove the sitecustomize.py file from the base python package.
This file was used tweak the python configuration after it was
incorrectly initialized. That's no longer necessary.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
|
|
|
|
|
|
This has been synonymous for ~5y.
|
|
super was incorrectly possible until https://github.com/NixOS/nixpkgs/pull/104201
got merged.
|
|
The integration tests code was included in the environment tests. After
this commit it is hopefully clearer what belongs together.
|
|
|
|
Test whether creating a virtualenv functions.
|
|
because the package that is used as part of the test does not support
older versions.
|
|
The prefix will now be correct in case of Nix env.
Note, however, that creating a venv from a Nix env still does not function. This does not seem to be possible
with the current approach either, because venv will copy or symlink our Python wrapper. In case it symlinks
(the default) it won't see a pyvenv.cfg. If it is copied I think it should function but it does not...
|
|
|
|
|
|
This adds tests to the passthru of all Python interpreters.
|