Repository navigation
poetry re-installs up-to-date packages when virtualenvs.create is false #1711
Description
-
I am on the latest Poetry version. (
1.0.0b9) -
I have searched the issues of this repo and believe that this is not a duplicate.
-
If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption). -
OS version and name: Debian buster
-
Poetry version:
1.0.0b9
Issue
Thanks for the great work! With current releases we experience that already up-to-date packages (with the correct versions) are reinstalled by poetry, as it tries to update them. This seems to happen because we don't use poetry's virtualenv feature (using poetry config virtualenvs.create false).
Here's a part of the poetry install output, when running it the second time:
- Updating humanfriendly (4.18 /usr/local/lib/python3.6/dist-packages -> 4.18)
- Updating imageio (2.6.1 /usr/local/lib/python3.6/dist-packages -> 2.6.1)
- Updating importlab (0.5.1 /usr/local/lib/python3.6/dist-packages -> 0.5.1)
It seems that dist-packages can never match the version, so poetry tries to upgrade them, even when the version actually matches.
Output of poetry debug info:
Poetry
Version: 1.0.0b9
Python: 3.6.8
Virtualenv
Python: 3.6.8
Implementation: CPython
Path: NA
System
Platform: linux
OS: posix
Python: /usr
Activity
jstriebel commentedon Dec 13, 2019
Just tested this again with poetry
1.0.0, this behavior did not change.#1732 seems to be a duplicate of this one.
etijskens commentedon Dec 16, 2019
a similar problem:
I would like to deploy my projects on a HPC cluster. On this system Python versions are made available by loading modules, and they come with a number of pre-installed python packages that are optimised for our hardware, e.g. numpy 1.17.0. I create a virtual environment in the project root directory like this:
python -m venv .venv --system-site-packagesIn this way the optimised Numpy is visible in the virtual environment. My project has a dependency
numpy = "^1.17.0"specified in the pyproject.toml file. When runningpoetry installit updates to the latest numpy 1.17.4. The newly installed numpy is not optimised for our hardware and in addition it consumes a lot of my file quota on the machine. This is certainly not desired behaviour, at least not in my case. Is there a way to tell poetry not to update if there is a version available that satisfies the version specification?etijskens commentedon Dec 16, 2019
On the other hand
pip install my_projectdoes exactly what I need - with exactly the same requirements. It looks to me thatpoetry installbehaves rather aspoetry update.Still I would expect
poetry installnot to install dependencies if they are already present in thevirtual environment and satisfy the requirements, or at least to have a switch available to make it do so, although I do not see the need for a
poetry updatecommand in that casesimoncoulton commentedon Dec 17, 2019
Noticing this here as well. This is particularly an issue with docker multistage builds and anything that requires psycopg2 (since you want your containers to be small, you're doing any build from source related tasks in the build stage, but then Poetry tries to reinstall it and it crashes and burns).
EDIT: Works fine with 0.12.17
jstriebel commentedon Dec 17, 2019
@etijskens This issue is about re-installing exactly the same version. One part of your issue can be solved by fixing the exact version in the
pyproject.toml, e.g.numpy = "1.17.0". Unfortunately you will then run into the problem this issue is about, because even then the package will be re-installed, which should not be the case. If you don't need the poetry1.0.0features using an older poetry version (e.g.0.12.17) might be a viable workaround for you.jstriebel commentedon Jan 7, 2020
Thanks @sdispater, I can confirm that this is fixed in the current master 👍
jstriebel commentedon Jan 14, 2020
@sdispater Unfortunately the same issue is happening now with poetry
1.0.1and1.0.2forsite-packages. I opened a seperate issue for this, #1882.github-actions commentedon Mar 3, 2024
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.