You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When installing a package with a dependency that is already installed but needs downgrading, pip downgrades the required dependency ,but then fails and complains about not finding the original version of the dependency anymore.
Expected behavior
Pip shouldn't look for a previously installed version if it has itself just changed that version, I guess, but not sure about the details of what's going on.
pip version
23.1.2
Python version
3.9.16
OS
Linux/Amd64
How to Reproduce
I'm working on a mac with apple silicon, but this occurs on linux/amd64, so the minimal steps to reproduce for me are:
So what seems to happen is that we start with wrapt=1.15.0. One of the two packages to be installed requires wrapt<=1.15 and the other wrapt>=1.11, which seem to be compatible. Pip first satisfies wrapt<=1.15 by uninstalling the current wrapt version and installing wrapt=1.14. So far so good. But then, when it seems to get to the second package to be installed, it isn't aware of having just replaced the wrapt version, and keeps looking for the previously installed version (1.15) which obviously it can't find anymore, and therefore fails the install.
Is this just a limitation of how Pip resolves (or doesn't resolve) dependencies, or is it a bug? At first the issue sounded related to #9129, but in this case conda doesn't really come into play, apart from creating the base environment.
chars2vec runs a pip install command in its setup.py. That seems like a very bad idea. It shouldn't be trying to install build dependencies itself, but rather should define them in its own build-system.requires setting.
I don't think we'd support running nested copies of pip like this. As a temporary fix, you could try building a wheel for chars2vec first and then using that in your install command, but the better solution is to get chars2vec to fix their build process.
Great catch, I hadn't noticed, and will try without that manual installation. I think I've seen the same happening with other packages though, so I'm not sure that's the cause. But I'll try and come back with more info 👍🏼
That sort of seems to work in this case, thanks so much! It doesn't really work, because it install both tensorflow-cpu and tensorflow (the GPU variant) and then crashes at runtime when trying to import tensorflow, but that's a different problem and I think expected under the rules of pip's dependency resolution (?). In any case, I'll close this issue and if the original problem pops up in another context (without the manual pip call in setup.py), I'll open a new one.
Description
When installing a package with a dependency that is already installed but needs downgrading, pip downgrades the required dependency ,but then fails and complains about not finding the original version of the dependency anymore.
Expected behavior
Pip shouldn't look for a previously installed version if it has itself just changed that version, I guess, but not sure about the details of what's going on.
pip version
23.1.2
Python version
3.9.16
OS
Linux/Amd64
How to Reproduce
I'm working on a mac with apple silicon, but this occurs on linux/amd64, so the minimal steps to reproduce for me are:
Inside the container create a minimal python environment:
Check what's inside:
Try pip install of these two packages:
Output
The above commands lead to this initial python environment:
Note that we have
wrapt=1.15.0
installed, with these files:INSTALLER AND REQUESTED are empty though, in case that's important.
The important bits from pip's verbose log are the following snippets (full log attached below):
pip-log.txt
So what seems to happen is that we start with
wrapt=1.15.0
. One of the two packages to be installed requireswrapt<=1.15
and the otherwrapt>=1.11
, which seem to be compatible. Pip first satisfieswrapt<=1.15
by uninstalling the currentwrapt
version and installingwrapt=1.14
. So far so good. But then, when it seems to get to the second package to be installed, it isn't aware of having just replaced thewrapt
version, and keeps looking for the previously installed version (1.15
) which obviously it can't find anymore, and therefore fails the install.Is this just a limitation of how Pip resolves (or doesn't resolve) dependencies, or is it a bug? At first the issue sounded related to #9129, but in this case conda doesn't really come into play, apart from creating the base environment.
Code of Conduct
The text was updated successfully, but these errors were encountered: