-
Notifications
You must be signed in to change notification settings - Fork 2.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
Poetry 1.0.0 always updates site-packages, is this expected behaviour? #1732
Comments
See also #1711, seems to be a duplicate. |
Yes, looks like the same problem! So I guess it's not expected behaviour. Should I close this? |
Closing as a duplicate of #1711. |
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:
In this way the optimised Numpy is visible in the virtual environment. My project has a dependency |
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. |
I've noticed that with 1.0.0,
poetry
is now always updating packages insite-packages
, even if no different version is available and no update is necessary:In this case, it replaces
numpy
with the same version, but installed viapoetry
and notconda
.If this is the expected behaviour, it catastrophically breaks my workflow for having a fast
numpy
(i.e. theconda
distribution linked againstmkl
) coexist with proper dependency management viapoetry
.Currently, I (and many colleagues in the high performance computing corner) do the following:
conda
environment withnumpy
,scipy
venv
with--system-site-packages
, installpoetry
, disablevenv
creation withpoetry
pyproject.toml
specifying the exactnumpy
version already installed, and additional dependencies thatpoetry
should manageThis results in (largely) properly managed dependencies for "pure python" packages and fast numerical packages. With this change, this is no longer possible.
Thanks, Marcel.
The text was updated successfully, but these errors were encountered: