Bug 1062084

`python-docker-py` has been renamed to `python-docker`.  The new package obsoletes and provides the old one.  However, it obsoletes `python2-docker-py`, NOT `python-docker-py`.  This is because of some magic in the specfile.  The easiest fix is to change all packages that depend on `python{2,3}-docker{,-py}`.

The best fix, however, would be to properly obsolete `python-docker-py`.  But that involves Specfile magic that I don't possess.

(In reply to Carmen Bianca Bakker from comment #1)
> `python-docker-py` has been renamed to `python-docker`.  The new package
> obsoletes and provides the old one.  However, it obsoletes
> `python2-docker-py`, NOT `python-docker-py`.  This is because of some magic
> in the specfile.  The easiest fix is to change all packages that depend on
> `python{2,3}-docker{,-py}`.
> 
> The best fix, however, would be to properly obsolete `python-docker-py`. 
> But that involves Specfile magic that I don't possess.

In the python-docker package in Factory I see:

# docker-py got renamed to docker in 2017                                       
Obsoletes: python-docker-py < %{version}                                        
Provides:  python-docker-py = %{version} 

Which seems right to me...

(In reply to Jordi Massaguer from comment #2)
> (In reply to Carmen Bianca Bakker from comment #1)
> > `python-docker-py` has been renamed to `python-docker`.  The new package
> > obsoletes and provides the old one.  However, it obsoletes
> > `python2-docker-py`, NOT `python-docker-py`.  This is because of some magic
> > in the specfile.  The easiest fix is to change all packages that depend on
> > `python{2,3}-docker{,-py}`.
> > 
> > The best fix, however, would be to properly obsolete `python-docker-py`. 
> > But that involves Specfile magic that I don't possess.
> 
> In the python-docker package in Factory I see:
> 
> # docker-py got renamed to docker in 2017                                   
> 
> Obsoletes: python-docker-py < %{version}                                    
> 
> Provides:  python-docker-py = %{version} 
> 
> Which seems right to me...

But:

rpm -qp binaries/python2-docker-2.4.2-1.1.noarch.rpm --obsoletes
python-docker < 2.4.2-1.1
python2-docker-py < 2.4.2

So, yes, this is kind of magic...

I think this should be fixed in the python-docker package.

I don't mean to be pushy, sorry, but docker-compose is really not a second zone piece of software for work/production.

And the fix does not seem difficult.

Could it be fixed soon?

I'll look into applying the easy fixes for you.  In the meantime, you can just accept broken dependencies for docker-compose, and manually make sure that python2-docker is installed.

Thanks! I did but then the docker command would fail too.

I just found a workaround with the virtualization extra repository, which does not have the issue.

Not ideal but ok for my test machine.

I also got this issue in TW:

panos:/home/panos/vpn # zypper se -s docker-compose
Loading repository data...
Reading installed packages...

S | Name           | Type       | Version   | Arch   | Repository                
--+----------------+------------+-----------+--------+---------------------------
  | docker-compose | package    | 1.8.1-1.2 | noarch | Main Repository (OSS)     
  | docker-compose | srcpackage | 1.8.1-1.2 | noarch | openSUSE-Tumbleweed-Source
panos:/home/panos/vpn # zypper in docker-compose
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides python-docker-py >= 1.10.3 needed by docker-compose-1.8.1-1.2.noarch
 Solution 1: do not install docker-compose-1.8.1-1.2.noarch
 Solution 2: break docker-compose-1.8.1-1.2.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): ^C

I guess the fix is not out yet...

Anyway I will add a test in Tumbleweed and Kubic to prevent this from happening again :)

Thank you Carmen for fixing the spec file. It now installs but when calling docker-compose it still tries to make use of docker-py.
I did some testing with fixing that in setup.py inside docker-compose and this seems to work, but this unveiled the real problem with docker-compose:

pkg_resources.DistributionNotFound: The 'docker<2.0,>=1.10.3' distribution was not found and is required by docker-compose

These are the requirements for docker-compose 1.8.1 according to the setup.py file:

install_requires = [
    'cached-property >= 1.2.0, < 2',
    'docopt >= 0.6.1, < 0.7',
    'PyYAML >= 3.10, < 4',
    'requests >= 2.6.1, < 2.8',
    'texttable >= 0.8.1, < 0.9',
    'websocket-client >= 0.32.0, < 1.0',
    'docker >= 1.10.3, < 2.0',
    'dockerpty >= 0.4.1, < 0.5',
    'six >= 1.3.0, < 2',
    'jsonschema >= 2.5.1, < 3',
]

So on Tumbleweed python2-docker is at version 2.5.1 and out of range for this version of docker-compose. This means that this version of docker-compose won't work with current version of Tumbleweed because the requirements are not met.

I also looked into more recent versions of docker-compose that might meet the requirements (e.g. docker-compose version 1.10.0 which requires pyhton2-docker version 2.5.1) but then other requirements e.g. python2-requests are too new in Tumbleweed (requested version by docker-compose is 'requests >= 2.6.1, != 2.11.0, < 2.12', in Tumbleweed is version 2.18.4).

That makes it almost impossible to use docker-compose in current Tumbleweed...

I will also check with other docker-compose versions...

So maybe it is time to update?

Latest stable release is 1.16.1, and provided by arch for instance.

So 1.8 branch is clearly outdated.

It is terrible that such major piece of software is broken on openSUSE.

(In reply to jean-christophe baptiste from comment #8)
> Thanks! I did but then the docker command would fail too.
> 
> I just found a workaround with the virtualization extra repository, which
> does not have the issue.

I am hit by the same issue. Where would I find that repo?

Nevermind. What solved it for me, for now, was this:

zypper in python-docker-py-1.10.6
zypper in docker-compose # Select 'Solution 2: break docker-compose-1.8.1-42.1.noarch by ignoring some of its dependencies'

I prepared an updated version(1.8.1 => 1.17.0) of docker-compose in request https://build.opensuse.org/request/show/539137

Hope that gets accepted soon :)

Good news, thanks !

Thanks people.

I was waiting for this correction too !

Regards.

Thanks, runtime is fixed with the update!

*** Bug 1067588 has been marked as a duplicate of this bug. ***

*** Bug 1063585 has been marked as a duplicate of this bug. ***

*** Bug 1067786 has been marked as a duplicate of this bug. ***

https://build.opensuse.org/request/show/539137 is a submission en-route to the devel project and is still not accepted. And since this is not even yet on the way to Factory, we can't expect Tumbleweed to magically get fixed

Just accepted the fix in devel project and it is currently on it's way to Factory.

Today it's fixed in openQA:

> BEFORE: https://openqa.opensuse.org/tests/539308#step/docker_compose/13
> AFTER: https://openqa.opensuse.org/tests/540294#step/docker_compose/12

-> FIXED

Congrats to everyone worked on this :D

SUSE-RU-2021:4019-1: An update that has one recommended fix and contains one feature can now be installed.

Category: recommended (moderate)
Bug References: 1062084
CVE References: 
JIRA References: SLE-22450
Sources used:
SUSE Linux Enterprise Module for Containers 12 (src):    python-dockerpty-0.4.1-8.3.1, python-expects-0.9.0-2.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

This is an autogenerated message for OBS integration:
This bug (1062084) was mentioned in
https://build.opensuse.org/request/show/940713 Backports:SLE-12-SP5 / docker-compose+python-docker