Compose: pip install of docker-compose 1.7.1 fails

Created on 7 May 2016  Â·  20Comments  Â·  Source: docker/compose

DESCRIPTION

On Ubuntu Trusty Tahr 14.04, pip install of docker-compose does not install all the dependencies it seems, so running docker-compose results in traceback:

$ sudo pip install docker-compose
$ docker-compose
Traceback (most recent call last):
  File "/usr/local/bin/docker-compose", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2749, in <module>
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 446, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 459, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 628, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: backports.ssl-match-hostname>=3.5

This can be fixed by updating the dependent package:

$ sudo pip install backports.ssl_match_hostname --upgrade
kinquestion

Most helpful comment

I prefer using the force upgrade for this

$ sudo pip install docker-compose --force --upgrade

All 20 comments

Our pip install docs suggest that you should use a virtualenv to prevent issues like this.

I usually use docker for Python segregation, rather than virtualenv. But regardless, there's an absolute requirement for backports.ssl-match-hostname to be at version 3.5 or greater. I am not familiar with Python packaging, but should this be a requirement for this version during pip install?

Separately from missing requirements, should a traceback be the UI for end users for a missing package? Non-developers may use this for ops purposes in testing containers.

The package you mention is a requirement for docker-py==1.8.1 which itself is a requirement for docker-compose==1.7.1. pip should recognize those dependencies provided the system packages don't interfere, which is why @dnephin mentioned using virtualenv.

If your end goal is to execute docker-compose commands from within a container, you might find the official image to be useful as well: https://hub.docker.com/r/docker/compose/

HTH

My use case was to use docker-compose on Ubuntu Trusty (not in a container). I am running docker-compose from the command line, dynamically create a test container (node express app) and run a test wrapper script from within the test container.

I noticed the issue came up when installing docker-compose on Ubuntu Trusty. When I manually installed the component in question, everything was fine. It could be I have a niche case, so it won't happen for many people. I just figured a backtrace wasn't the desired feedback for the user, as non-programmers might use docker-compose.

Just had this problem while installing docker-compose on CentOS. Thanks for the workaround.

@shin- I am not executing docker-compose within a container. I am using it on a base Ubuntu 14.04 system. From that system, I call docker-compose. My project requires use of the .env to have default environment variables in my docker-compose.yml, which sort of interferes with virtualenv's use of a .env directory.

@darkn3rd I believe you're commenting on the wrong issue. This on the other hand should be relevant: #3399

You should update the dependent package backports.ssl_match_hostname:

[sudo] pip install --upgrade backports.ssl_match_hostname

I prefer using the force upgrade for this

$ sudo pip install docker-compose --force --upgrade

Going to +1 this, Docker Compose 1.8.0 fails in the same way on a stock Oracle Linux 7 installation (Meaning this fails on CentOS and RHEL as well)

yum install python-pip
pip install -U pip
pip install docker-compose

Running Docker-Compose at this point from the standard command line provides the traceback error.

--force or --upgrade should NOT be needed on any command lines given docker-compose is not there by default and this is NOT an upgrade installation.

Please either document the need to pip install backports.ssl_match_hostname or include it within the dependencies because it's NOT getting resolved correctly.

Are we suggesting the default system packages are getting in the way of the pip installation of docker understanding that backports.ssl_match_hostname is a dependency?

I'm experiencing this issue as well. Cannot install docker-compose into virtualenv:

(venv)➜  gitlab git:(master) ✗ docker-compose up                                                   
Traceback (most recent call last):
  File "/usr/local/bin/docker-compose", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2953, in <module>
    @_call_aside
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2939, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2966, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 637, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 650, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 829, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'backports.ssl-match-hostname>=3.5; python_version < "3.5"' distribution was not found and is required by docker-py
(venv)➜  gitlab git:(master) ✗ pip freeze
PyYAML==3.12
argparse==1.2.1
backports.ssl-match-hostname==3.5.0.1
cached-property==1.3.0
docker-compose==1.8.1
docker-py==1.10.3
docker-pycreds==0.2.1
dockerpty==0.4.1
docopt==0.6.2
enum34==1.1.6
functools32==3.2.3-2
ipaddress==1.0.17
jsonschema==2.5.1
requests==2.10.0
six==1.10.0
texttable==0.8.4
websocket-client==0.37.0
wsgiref==0.1.2

This is still a problem even with the latest docker-compose and CentOS or Ubuntu :( .

I confirm that problem still persists:

[drasko@zebra mainflux]$ docker-compose up
Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3011, in <module>
    parse_requirements(__requires__), Environment()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: backports.ssl-match-hostname>=3.5

I am not sure why, but I solved issue by theses commands
export http_proxy=http://proxyXXX:8088/
export https_proxy=https://proxyXXX:8088/

pip install docker-compose --force --upgrade

I really hope compose will become a part of docker one day. So we can all just do docker compose and be happy... :)

You can also use the docker/compose image, something like this in your .profile removes a lot of pain;

docker-compose() {  docker run -it --rm -w /data/$(basename ${PWD}) -v /var/run/docker.sock:/var/run/docker.sock -v ${PWD}:/data/$(basename ${PWD}) docker/compose:1.9.0 "$@"; }

Your docker-compose function should handle most of what we normally use it for now. Even tho it now takes half a second extra to start..

Fix my problem

sudo apt-get install build-essential autoconf libtool pkg-config python-opengl python-imaging python-pyrex python-pyside.qtopengl idle-python2.7 qt4-dev-tools qt4-designer libqtgui4 libqtcore4 libqt4-xml libqt4-test libqt4-script libqt4-network libqt4-dbus python-qt4 python-qt4-gl libgle3 python-dev

sudo easy_install greenlet

sudo easy_install gevent

sudo pip install docker-compose --force --upgrade

why cannt it be specified in setup.py install_requires?

thanks, works for me.

From the @shin-'s above comments, docker-compose requires a module previously known as docker-py. That pip module for whatever reason did not cause a fuss during installation. I am not sure of the minimal code snippet to reproduce this with docker python module (previously known as docker-py), otherwise, would write another bug on that module as well. Bottom line, this was installed without the dependency, and there does not seem to be much concern about that or further digging (probably too busy adding swarm features). Also, having traceback as a form of feedback, I guess is acceptable, as I didn't get comment on that. At least we have some workarounds.

Thanks for the excellent feedback. What worked for me on Linux Mint 19.2 (plain vanilla install) was

sudo apt-get install python3-setuptools
sudo pip install docker-compose --force --upgrade
Was this page helpful?
0 / 5 - 0 ratings