-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pip>=20.2 needlessly re-installs dependencies available on the system in system-site-packages venv #8695
Comments
I can reproduce. It might be a side effect of changes made to |
This is due to the |
Can confirm, also have the same issue. |
@fdebrabander the issue is fixed in #8702 and should be part of the next patch release. You can test it by installing that branch with |
Can also confirm; on Ubuntu 18.04 with $ mkdir -p ~/venv/sys
$ (
set -eu
cd ~/venv/sys
rm -rf ./*
python3 -m virtualenv -p python3 --system-site-packages .
source bin/activate
pip install pip==20.2.1
pip install numpy
)
...
Successfully installed numpy-1.19.
$ (
set -eu
cd ~/venv/sys
rm -rf ./*
python3 -m virtualenv -p python3 --system-site-packages .
source bin/activate
pip install pip==20.2
pip install numpy
)
...
Requirement already satisfied: numpy in /usr/lib/python3/dist-packages (1.13.3) |
FWIW Our investigation in #8726 was motivated by us running into this problem. Something to note is that this new behavior does seem to be in line with what these docs say about
|
Eh, not sure about the direct correlation, tho. 20.2.1 was released on Aug. 4. The commit that introduced these docs (5da3a7d) was made back in Feb. EDIT: Didn't read upstream thread. Source was root-caused - sorry for the noise! |
Updating the pip package within the virtualenv adds another uncertainty (and reduces reproducibility). Thus we should stick to the version shipped in the docker base image. Specifically the upgrade from pip 2.2.0 to 2.2.1 broke the handling of "--system-site-packages" and thus causes build failures. (see pypa/pip#8695)
Updating the pip package within the virtualenv adds another uncertainty (and reduces reproducibility). Thus we should stick to the version shipped in the docker base image. Specifically the upgrade from pip 2.2.0 to 2.2.1 broke the handling of "--system-site-packages" and thus causes build failures. (see pypa/pip#8695)
Updating the pip package within the virtualenv adds another uncertainty (and reduces reproducibility). Thus we should stick to the version shipped in the docker base image. Specifically the upgrade from pip 2.2.0 to 2.2.1 broke the handling of "--system-site-packages" and thus causes build failures. (see pypa/pip#8695)
Updating the pip package within the virtualenv adds another uncertainty (and reduces reproducibility). Thus we should stick to the version shipped in the docker base image. Specifically the upgrade from pip 2.2.0 to 2.2.1 broke the handling of "--system-site-packages" and thus causes build failures. (see pypa/pip#8695)
162: Update pip to 20.2.2 r=duckinator a=pyup-bot This PR updates [pip](https://pypi.org/project/pip) from **20.2.1** to **20.2.2**. <details> <summary>Changelog</summary> ### 20.2.2 ``` =================== Bug Fixes --------- - Only attempt to use the keyring once and if it fails, don't try again. This prevents spamming users with several keyring unlock prompts when they cannot unlock or don't want to do so. (`8090 <https://github.com/pypa/pip/issues/8090>`_) - Fix regression that distributions in system site-packages are not correctly found when a virtual environment is configured with ``system-site-packages`` on. (`8695 <https://github.com/pypa/pip/issues/8695>`_) - Disable caching for range requests, which causes corrupted wheels when pip tries to obtain metadata using the feature ``fast-deps``. (`8701 <https://github.com/pypa/pip/issues/8701>`_, `8716 <https://github.com/pypa/pip/issues/8716>`_) - Always use UTF-8 to read ``pyvenv.cfg`` to match the built-in ``venv``. (`8717 <https://github.com/pypa/pip/issues/8717>`_) - 2020 Resolver: Correctly handle marker evaluation in constraints and exclude them if their markers do not match the current environment. (`8724 <https://github.com/pypa/pip/issues/8724>`_) ``` </details> <details> <summary>Links</summary> - PyPI: https://pypi.org/project/pip - Changelog: https://pyup.io/changelogs/pip/ - Homepage: https://pip.pypa.io/ </details> Co-authored-by: pyup-bot <[email protected]>
What did you want to do?
We are using a venv that explicitly does use system-site-packages, in order to allow users in a container, which does not allow write access to /, to install their own packages while still using all the (partially very complex to install/build) packages provided by the container image.
This used to work fine until pip>=20.2, and is still broken in latest pip dev build as of today.
Output
As you can see, before updating pip to 20.2, it correctly notices that numpy is already installed and does not need to do anything.
After the update, it goes and installs a copy of the same numpy version in the venv.
The same happens when installing a package that depends on numpy. Also the same goes for any other dependency that's already provided by the system site-packages.
"pip list" correctly lists numpy as installed in either case.
Additional information
The reason we are doing it this way is because building some of those dependencies, which are binary and annoying to deal with (most prominently gdal and fiona). The singularity container image has all of them pre-built, with optimizations specific for the host systems CPU.
For now I've instructed users to either use --no-deps when installing things, or to explicitly pin pip to <20.2.
The text was updated successfully, but these errors were encountered: