The fix merged in 3b60e36289 also fixed
the wheel cache; this cherry-picks the test and news from the other pull
request to validate and document the fact.
This implements the PEP 668 logic to 'pip install' and 'pip uninstall'.
Are there any other commands that may need it?
This implementation disables the check is any of --prefix, --home, or
--target is provided, since those can indicate the command does not
actually install into the environment. Note that it is still possible
the command is still modifying the environment, but we don't have a
way to stop the user *that* determined to break the environment anyway
(they can always just use those flags in a virtual environment).
Also not sure how best this can be tested.
The scripts path was looked up passing explicitly the scheme to be
used using "nt" on Windows and "posix_prefix" everywhere else.
However, when the isolated build environment is created, packages are
installed using the default scheme for the platform. On most platforms
this works because normally "nt" and "posix_prefix" are the default
schemes.
However, Debian customizes sysconfig to use a "posix_local" scheme by
default and under this scheme the scripts path does not match the one
of the "posix_prefix" scheme. This results in scripts installed as
part of the build dependencies not to be found during the build, as
reported here https://github.com/mesonbuild/meson-python/issues/109
and here https://bugs.debian.org/1019293.
The problem can be solved omitting to specify a scheme when looking up
the scripts path. To future proof the path lookup, use the "venv"
scheme if available as done in #11598. For uniformity use similar
functions as used to lookup the library paths.
get_prefixed_libs() computes the Python path for libraries in a pip
isolation environment. Python 3.11 introduced the "venv" path scheme
to be used in these cases. Use it if available.
This solves a bug on Homebrew's Python 3.10 and later where the
default paths scheme when Python is invoked outside a virtual
environment is "osx_framework_library" and does not relative to the
"{base}" or "{platbase}" variables.
Fixes#11539.
Previously, the special case to generate 'pip' and 'easy_install' entry
points with the correct Python version (e.g. 'pip3.9' on Python 3.9)
only accounted for single-digit version segments, and did not work
correctly on Python 3.10 and up. This was missed when Python 3.10 was
released because we (accidentally) generated wheels that did not need
any such replacements, but was exposed in CPython 3.11.0 since it
bundled pip 22.3 generated against Python 3.10.
Git 2.38.1 patched CVE-2022-39253 by disaling automated fetch against a
file: repository. This breaks git submodule, which is used by a pip
test. Information on how projects relying on automated fetch should
configure git correctly after this change is lacking, so the test is
disabled for now until someone can come up with a better solution.
The tests still don't run without distutils
because they require virtualenv < 20 (and virtualenv 16 uses distutils),
but at least they don't import distutils directly now.
Fixes https://github.com/pypa/pip/issues/11521
shlex.split, used to split options in requirements.txt files, might
raise a ValueError when the input string is not well formed. Catch the
ValueError and re-raise it as a RequirementsFileParseError instead.
The new functionality serves a use case which was not previously possible with pip configuration files, namely the situation where you have a base Python installation and want to influence the pip configuration for all derivative virtual environments *without* changing the config for all other environments on a machine (global), or for all other environment run by the same user (user). Concretely, this could be used for a centrally managed network mounted filesystem based Python installation, from which multiple users can build virtual environments and inside which a specific pip configuration is needed (e.g. an index URL).
This patch adds a special check-job that produces a clear failure or
success status based on how the dependent jobs are doing. It is
possible to use it in GitHub's branch protection instead of having to
manually add and remove individual job names via the repo settings.
https://github.com/marketplace/actions/alls-green#why
use site.getsitepackages() where available
instead of just purelib/platlib,
which is often insufficient on e.g. System Pythons for Debian/macOS
handle virtualenv < 20 overwriting site.py without getsitepackages() by preserving current behavior.
