docker-compose error on Fedora 25: DistributionNotFound

[szokekaroly-zz]

When I run docker-compose command in bash, I got the following error message:

$ docker-compose
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/__init__.py", line 2958, in <module>
    @_call_aside
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2944, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2971, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 637, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 650, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 829, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'texttable<0.9,>=0.8.1' distribution was not found and is required by docker-compose

Environment:

Fedora 25 kernel 4.10.15-200.fc25.x86_64
Docker version 1.12.6, build ae7d637/1.12.6
docker-compose version 1.9.0, build 2585387
pip 9.0.1 from /usr/lib/python2.7/site-packages (python 2.7)
pip show texttable:
Name: texttable
Version: 0.9
Summary: module for creating simple ASCII tables

My workaround was:

# pip install pip-conflict-checker
# pipconflictchecker
--------------------------------------------------
 Conflicts Detected
--------------------------------------------------
 - texttable(0.9.0) docker-compose(>=0.8.1,<0.9)
# pip uninstall texttable
# pip install texttable ==0.8.1
# docker-compose 
Define and run multi-container applications with Docker.
$ pip show texttable
Name: texttable
Version: 0.8.1
Summary: module for creating simple ASCII tables
...

[remiflament]

I have fix it by using this command :

sudo dnf install python-texttable.noarch --allowerasing

It will be remove the packet python2-texttable and install the python-textable

[givaha]

I have fixed it by using the follow commands in this order:

While executing some commands, it will give still some error messages between the commands but after executing 6. , my docker-compose file builds en runs again.

1. pip install --upgrade pip
2. sudo pip install --upgrade docker-compose
3. sudo pip uninstall docker-py
4. sudo pip uninstall docker
5. sudo pip install docker
6. sudo easy_install --upgrade pip

[carlwgeorge]

This is due to a bogus upper limit set in the setup.py file for the texttable dependency.

 'texttable >= 0.8.1, < 0.9',

This upper limit was set in 2014, while texttable 0.9.0 was just released last week, so it would have been literally impossible for there to be an actual know conflict.

This was also reported to Fedora already, and has been fixed in docker-compose-1.9.0-3.fc25, currently available in the updates-testing repository.

[shin-]

1. Always use virtualenv when installing Python packages, for exactly this reason.
2. An upper limit set pre-emptively is not "bogus". It protects against potential API changes that would prevent our software from functioning properly. When an "actual conflict" happens, it's already too late.

[carlwgeorge]

Always use virtualenv when installing Python packages, for exactly this reason.

Virtual environments are a great development tool, but expecting every user to keep hundreds of copies of the same libraries installed across multiple virtual environments is not realistic. Installing Python libraries in the system site-packages via the distribution package manager is a valid and reasonable choice.

It protects against potential API changes that would prevent our software from functioning properly.

Very few projects actually follow semantic versioning correctly. A more balanced approach would be to only set this preemptive upper limit on major version bumps, which would have been < 1.0.0 in this case. This was done for most of the other dependencies. In the rare case that an actual conflict occurs in a minor release, it's trivial to change the speculative upper limit into a truthful one with a bug fix release.

[shin-]

A more balanced approach would be to only set this preemptive upper limit on major version bumps, which would have been < 1.0.0 in this case.

See semver spec item 4. When the major version is 0, it is common for API changes to occur in minor version bumps.

[carlwgeorge]

Yet there is zero evidence that texttable follows semantic versioning. To that point, semver also says this:

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Which is clearly not the case here.

If you want to incorrectly believe every project strictly follows semver and feel the need to guard against API changes in minor version bumps, then why is the upper limit of websocket-client set to be the next major version?

 'websocket-client >= 0.32.0, < 1.0',

That's exactly the approach I am suggesting.

[llorllale]

I fixed this by installing it from the git repo:

sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

[jirios125]

I have fixed it by using the follow commands in this order:

While executing some commands, it will give still some error messages between the commands but after executing 6. , my docker-compose file builds en runs again.

1. pip install --upgrade pip
2. sudo pip install --upgrade docker-compose
3. sudo pip uninstall docker-py
4. sudo pip uninstall docker
5. sudo pip install docker
6. sudo easy_install --upgrade pip

This line works perfect to me pip install --upgrade docker-compose