We're running docker-compose on CentOS. The pip version when installed with --upgrade changed to 10.0.0 in the last couple days and our docker install (pip install docker-compose) began failing with the following message. It appears that pip 10.0.0 has increased the version dependency of package requests
to 2.6.0, which is incompatible with the default docker-compose installation.
Output of "docker-compose version"
N/A
Output of "docker version"
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:09:15 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:13:03 2018
OS/Arch: linux/amd64
Experimental: false
Output of "docker-compose config"
N/A
Install fails
Install succeeds
$ pip install docker-compose
...
Found existing installation: requests 2.6.0
Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
OS version / distribution, docker-compose
install method, etc.
I have the same issue. Workaround for now would be not to upgrade the pip to 10.x.
I also have same and downgrade pip to 9.0.3.
Also an issue on RHEL 7.4. Temporarily working around the problem by doing the same as @hermesian, using:
sudo pip install --upgrade --force-reinstall pip==9.0.3
After looking at this more closely, it looks like this is mostly a pip
/ Linux distribution issue:
My takeaway here is that it's not Compose's responsibility to fix, nor would we be able to even if we wanted to.
Downgrading pip
is probably a reasonable course of action for the short term (other reasonable options: virtualenv
, Compose binaries). In the long term, the way yum
installs some Python packages probably needs to change.
The same question
Found existing installation: requests 2.6.0
Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
And the issue still persists....
Most helpful comment
Also an issue on RHEL 7.4. Temporarily working around the problem by doing the same as @hermesian, using:
sudo pip install --upgrade --force-reinstall pip==9.0.3