-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker-compose error on Fedora 25: DistributionNotFound #4848
Comments
I have fix it by using this command :
It will be remove the packet python2-texttable and install the python-textable |
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.
|
This is due to a bogus upper limit set in the setup.py file for the texttable dependency.
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. |
|
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.
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 |
See semver spec item 4. When the major version is 0, it is common for API changes to occur in minor version bumps. |
Yet there is zero evidence that texttable follows semantic versioning. To that point, semver also says this:
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?
That's exactly the approach I am suggesting. |
Make setup.py satisfiable by API-compatible versions we have in ports. References: docker/compose#4848 https://bugzilla.redhat.com/show_bug.cgi?id=1452999 PR: 221744 Reported by: decke git-svn-id: svn+ssh://svn.freebsd.org/ports/head@448629 35697150-7ecd-e111-bb59-0022644237b5
Make setup.py satisfiable by API-compatible versions we have in ports. References: docker/compose#4848 https://bugzilla.redhat.com/show_bug.cgi?id=1452999 PR: 221744 Reported by: decke
I fixed this by installing it from the git repo:
|
This line works perfect to me pip install --upgrade docker-compose |
Make setup.py satisfiable by API-compatible versions we have in ports. References: docker/compose#4848 https://bugzilla.redhat.com/show_bug.cgi?id=1452999 PR: 221744 Reported by: decke
When I run docker-compose command in bash, I got the following error message:
Environment:
My workaround was:
The text was updated successfully, but these errors were encountered: