Description of problem: On my system (CentOS 7.5.1804), docker-compose throws a warning about an older version of docker-py polluting the python namespace: % docker-compose up WARNING: Dependency conflict: an older version of the 'docker-py' package may be polluting the namespace. If you're experiencing crashes, run the following command to remedy the issue: pip uninstall docker-py; pip uninstall docker; pip install docker Checking the entry script reveals that the interpreter for /usr/bin/docker-compose is /usr/bin/python3.4. The actual warning is produced in /usr/lib/python3.4/site-packages/compose/cli/__init__.py by running "pip freeze" and manually checking the output. On a pristine CentOS 7.5, "pip freeze" will display all modules installed for python2.7. However with docker-compose running under python 3.4, I think it would be more appropriate to additionally depend on python34-pip and replace pip-call with a call to pip3 or pip3.4 Version-Release number of selected component (if applicable): 1.18.0-1.el7 How reproducible: Create a docker-compose example and run docker-compose up. Steps to Reproduce: 1. Create a minimal docker-compose example 2. Run docker-compose up Actual results: docker-compose throws a warning about older python-docker versions being present on the system: WARNING: Dependency conflict: an older version of the 'docker-py' package may be polluting the namespace. If you're experiencing crashes, run the following command to remedy the issue: Expected results: Docker compose should only throw a warning, if the outdated python-docker-py is present on python3.4. Additional info:
Something installed from RPM shouldn't advise users to manipulate it's dependencies via pip. python34-docker is correctly pulled in just by installing docker-compose. python34-docker-py doesn't exist, but even if it did it would have file conflicts with python34-docker so you wouldn't be able to install both. I can see why upstream wants the check (pip doesn't care about file conflicts and just overwrites files, and will let you install both docker-py and docker), but it is pointless for the RPM. I've patched it out. https://src.fedoraproject.org/rpms/docker-compose/c/77a765799de7fae359edd8f4739452331e4b4284
docker-compose-1.18.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-33a4b596ca
Hi Carl, thanks for your quick response. (In reply to Carl George from comment #1) > Something installed from RPM shouldn't advise users to manipulate it's > dependencies via pip. python34-docker is correctly pulled in just by > installing docker-compose. python34-docker-py doesn't exist, but even if it > did it would have file conflicts with python34-docker so you wouldn't be > able to install both. I can see why upstream wants the check (pip doesn't > care about file conflicts and just overwrites files, and will let you > install both docker-py and docker), but it is pointless for the RPM. I've > patched it out. Not sure about virtualenvironments. Haven't tested it yet, but a user might be able to create a virtualenvironment that contains on older version of python-docker-py. In this case, the package in the venv would conflict with the system package from python34-docker and a warning might be appropriate. On the other Hand, this is somewhat expected when you mess with python packages on your system.
docker-compose-1.18.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-33a4b596ca
docker-compose-1.18.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.