Investigating the reverse dependencies of python-monotonic.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Investigating the reverse dependencies of python-monotonic.

peter green-2
Hi

I've been looking at various python 2 cruft packages (packages no longer built by the corresponding source packages) and why they can't be cleaned up, I have been looking in a derivative but many of my results are also relevant to debian proper. Where relevant I have been filing bugs against the reverse-dependencies of these cruft packages, so they can be fixed or ultimately removed.

Most such packages have been part of upstream projects that have dropped python 2 support, notablly django and openstack. In such cases it is pretty clear that the only reasonable way forward is for the reverse dependencies to be either removed or migrated to python 3.

One package that stood out from the rest was python-monotonic. python-monotonic is maintained by the Debian openstack team, but it doesn't seem to be in any way openstack specific, nor does upstream seem to have dropped python2 support. It seemed to have a fair few reverse dependencies.

python-humanfriendly (has rdeps)
oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 )
python-fasteners (has rdeps)
python-futurist (has rdeps, cruft)
python-octaviaclient (assumed to be openstack related)
python-oslo.log (assumed to be openstack related)
python-oslo.messaging (assumed to be openstack related)
python-oslo.service (assumed to be openstack related)
python-oslo.utils (assumed to be openstack related)
python-tenacity (has rdeps, cruft)

There are also indirect reverse dependencies, (i'm not investigating reverse dependencies of packages that are clearly openstack specific here)

python-coloredlogs (via python-humanfriendly, no reverse dependencies)
python-datalad (via python-fasteners, no reverse dependencies)
duplicity (via python-fasteners)
python-oauth2client (via python-fasteners)
python-oslo.concurrency (via python-fastners, openstack related)
python-taskflow (via python-fasteners, cruft)
python-tooz (via python-fasteners, openstack related, cruft)
python-googleapi (via python-oauth2client)
python-pypowervm (via python-taskflow, openstack related, cruft)
python-googleapi-samples (via python-googleapi)
python-etcd3gw (no rdeps)
python-gnocchiclient (openstack related, cruft)

If we ignore openstack stuff, python modules and an examples package the two main packages left seem to be oz and duplicity, oz seems to have very low popcon, but duplicity seems to have a popcon of around 3000 and growing.

So the main question seems to be can duplicity be reasonably migrated to python 3 and if not is it worth reinstating the python-monotonic binary package to save duplicity?


Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Andrey Rahmatullin-3
On Tue, Aug 13, 2019 at 11:38:33AM +0100, peter green wrote:

> One package that stood out from the rest was python-monotonic. python-monotonic is maintained by the Debian openstack team, but it doesn't seem to be in any way openstack specific, nor does upstream seem to have dropped python2 support. It seemed to have a fair few reverse dependencies.
>
> python-humanfriendly (has rdeps)
> oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 )
> python-fasteners (has rdeps)
> python-futurist (has rdeps, cruft)
> python-octaviaclient (assumed to be openstack related)
> python-oslo.log (assumed to be openstack related)
> python-oslo.messaging (assumed to be openstack related)
> python-oslo.service (assumed to be openstack related)
> python-oslo.utils (assumed to be openstack related)
> python-tenacity (has rdeps, cruft)
>
> There are also indirect reverse dependencies, (i'm not investigating reverse dependencies of packages that are clearly openstack specific here)
>
> python-coloredlogs (via python-humanfriendly, no reverse dependencies)
> python-datalad (via python-fasteners, no reverse dependencies)
> duplicity (via python-fasteners)
> python-oauth2client (via python-fasteners)
> python-oslo.concurrency (via python-fastners, openstack related)
> python-taskflow (via python-fasteners, cruft)
> python-tooz (via python-fasteners, openstack related, cruft)
> python-googleapi (via python-oauth2client)
> python-pypowervm (via python-taskflow, openstack related, cruft)
> python-googleapi-samples (via python-googleapi)
> python-etcd3gw (no rdeps)
> python-gnocchiclient (openstack related, cruft)
>
> If we ignore openstack stuff, python modules and an examples package the two main packages left seem to be oz and duplicity, oz seems to have very low popcon, but duplicity seems to have a popcon of around 3000 and growing.
>
> So the main question seems to be can duplicity be reasonably migrated to python 3 and if not is it worth reinstating the python-monotonic binary package to save duplicity?
This is worrying, a package with revdeps shouldn't have been dropped.

By the way, you checked only deps, not build-deps, as at least
python-coloredlogs and python-datalad has reverse build-deps.

I've also noted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934333

As for duplicity, the latest upstream version (not packaged) support
Python 3.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

peter green-2
(note for people reading on bug 934333, the start of this thread can be found at https://lists.debian.org/debian-python/2019/08/msg00070.html )

On 13/08/2019 11:54, Andrey Rahmatullin wrote:
This is worrying, a package with revdeps shouldn't have been dropped.

AIUI a "go cleanly" approach was agreed at the Python BoF, but by that time an aggressive removal process was already well underway for django and openstack related packages.

By the way, you checked only deps, not build-deps, as at least
python-coloredlogs and python-datalad has reverse build-deps.

I took a look at the build-rdeps, also this time I used unstable whereas my previous analysis had been looking at buster (yeah, this made little sense, I was probablly meaning to use bullseye but mixed the words up in my head, not that I think it made any difference). Again i'm not investigating openstack related stuff. This seems to add a few more packages to our set

python-jira (via python-tenacity)
cyvcf2 (via python-coloredlogs, sid version has dropped the python2 stuff, but it's blocked from having old versions cleaned up and migrating to testing by build failures on mips*)
heudiconv (via python-datalad, sid only, never been in testing or a stable release, WTF was someone doing uploading a new python2 only package in 2019?!)
python-googlecloudapis (via python-oauth2client, sid only)
python-google-auth(via python-oauth2client, sid only)
rekall(via python-oauth2client)
python-oslo.cache (via python-etcd3gw, openstack related)
elastalert (via python-jira, also depends on python-croniter)

I've also noted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934333
ccing this mail there.

As for duplicity, the latest upstream version (not packaged) support
Python 3.
There is a bug report for it, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929949

In a response to bug 934333 Ondrej Novy wrote:
just my two cents: correct solution is to add Python 3.x support to
python-m2crypto and migrate oz to Python 3.
I agree that is the correct long term soloution, however as mentioned in this mail and in https://lists.debian.org/debian-python/2019/08/msg00070.html it's not just oz that is involved here.
Reintroduction Python2 support to python-monotonic is not good idea, we are
going to drop Python 2 completly from Debian.
I understand that dropping python 2 is the goal, but my understanding of https://lists.debian.org/debian-python/2019/07/msg00069.html and https://lists.debian.org/debian-python/2019/07/msg00080.html is the plan was to do it cleanly, starting with leaf stuff and working down the dependency stack.

IMO python-monotonic should be reinstated until it's reverse dependencies are sorted out.
Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Matthias Klose
On 13.08.19 15:30, peter green wrote:
> IMO python-monotonic should be reinstated until it's reverse dependencies are
> sorted out.

I agree with that.

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Thomas Goirand-3
In reply to this post by peter green-2
On 8/13/19 12:38 PM, peter green wrote:

> Hi
>
> I've been looking at various python 2 cruft packages (packages no longer
> built by the corresponding source packages) and why they can't be
> cleaned up, I have been looking in a derivative but many of my results
> are also relevant to debian proper. Where relevant I have been filing
> bugs against the reverse-dependencies of these cruft packages, so they
> can be fixed or ultimately removed.
>
> Most such packages have been part of upstream projects that have dropped
> python 2 support, notablly django and openstack. In such cases it is
> pretty clear that the only reasonable way forward is for the reverse
> dependencies to be either removed or migrated to python 3.
>
> One package that stood out from the rest was python-monotonic.
> python-monotonic is maintained by the Debian openstack team, but it
> doesn't seem to be in any way openstack specific, nor does upstream seem
> to have dropped python2 support. It seemed to have a fair few reverse
> dependencies.
>
> python-humanfriendly (has rdeps)
> oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 )
> python-fasteners (has rdeps)
> python-futurist (has rdeps, cruft)
> python-octaviaclient (assumed to be openstack related)
> python-oslo.log (assumed to be openstack related)
> python-oslo.messaging (assumed to be openstack related)
> python-oslo.service (assumed to be openstack related)
> python-oslo.utils (assumed to be openstack related)
> python-tenacity (has rdeps, cruft)
>
> There are also indirect reverse dependencies, (i'm not investigating
> reverse dependencies of packages that are clearly openstack specific here)
>
> python-coloredlogs (via python-humanfriendly, no reverse dependencies)
> python-datalad (via python-fasteners, no reverse dependencies)
> duplicity (via python-fasteners)
> python-oauth2client (via python-fasteners)
> python-oslo.concurrency (via python-fastners, openstack related)
> python-taskflow (via python-fasteners, cruft)
> python-tooz (via python-fasteners, openstack related, cruft)
> python-googleapi (via python-oauth2client)
> python-pypowervm (via python-taskflow, openstack related, cruft)
> python-googleapi-samples (via python-googleapi)
> python-etcd3gw (no rdeps)
> python-gnocchiclient (openstack related, cruft)
>
> If we ignore openstack stuff, python modules and an examples package the
> two main packages left seem to be oz and duplicity, oz seems to have
> very low popcon, but duplicity seems to have a popcon of around 3000 and
> growing.
>
> So the main question seems to be can duplicity be reasonably migrated to
> python 3 and if not is it worth reinstating the python-monotonic binary
> package to save duplicity?

What happened is that I simply uploaded the latest version of OpenStack
from Experimental to Sid. This includes monotonic. It's been a long time
I maintain monotonic because it's used in OpenStack, then other packages
started using it. You may have noticed that it was in Experimental with
Python 2 removed for at least 6 months, just like for Django, giving the
sign that Py2 would soon go away. However, maybe bugs should have been
filled, sorry that I didn't do it in time.

Let's take a look at the situation.

As per Andrey's reply, we can fix duplicity.

>From your report above, if I remove all the OpenStack stuff (which at
this time, should all be only Python 3), the only affected packages
would be:

> python-humanfriendly (has rdeps)
> oz (rc bug filed #933509)
> python-coloredlogs (via python-humanfriendly, no reverse dependencies)
> python-datalad (via python-fasteners, no reverse dependencies)
> duplicity (via python-fasteners)
> python-oauth2client (via python-fasteners)
> python-googleapi-samples (via python-googleapi)

According to the setup.py of python-googleapi in the Github repo, latest
upstream version supports Python 3, so it should be doable to upload a
new version to fix this.

I will remove Python 2 suport from python-oauth2client and
python-fasteners tomorrow.

So, this leaves us only: humanfriendly, oz, python-coloredlogs,
python-datalad. I've uploaded humanfriendly and coloredlogs Py2 removal.
BTW, I believe python-coloredlogs was there as a build-depends of
cyvcf2, which has been fixed on the 1st of august by Andreas Tille.

By all means, let's not play the dance of re-introducting Python 2 when
we can move forward on the right direction.

Thanks for taking the time to investigate this, this is very useful, and
I have to admit that, even though I know how to do the work, I am a bit
lost into knowing from were to begin. The release tracker is not very
helpful in this regard.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Simon Josefsson-2
Once python3-m2crypto is in Debian, I will port oz to python3.

/Simon

> 13 aug. 2019 kl. 21:46 skrev Thomas Goirand <[hidden email]>:
>
>> On 8/13/19 12:38 PM, peter green wrote:
>> Hi
>>
>> I've been looking at various python 2 cruft packages (packages no longer
>> built by the corresponding source packages) and why they can't be
>> cleaned up, I have been looking in a derivative but many of my results
>> are also relevant to debian proper. Where relevant I have been filing
>> bugs against the reverse-dependencies of these cruft packages, so they
>> can be fixed or ultimately removed.
>>
>> Most such packages have been part of upstream projects that have dropped
>> python 2 support, notablly django and openstack. In such cases it is
>> pretty clear that the only reasonable way forward is for the reverse
>> dependencies to be either removed or migrated to python 3.
>>
>> One package that stood out from the rest was python-monotonic.
>> python-monotonic is maintained by the Debian openstack team, but it
>> doesn't seem to be in any way openstack specific, nor does upstream seem
>> to have dropped python2 support. It seemed to have a fair few reverse
>> dependencies.
>>
>> python-humanfriendly (has rdeps)
>> oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 )
>> python-fasteners (has rdeps)
>> python-futurist (has rdeps, cruft)
>> python-octaviaclient (assumed to be openstack related)
>> python-oslo.log (assumed to be openstack related)
>> python-oslo.messaging (assumed to be openstack related)
>> python-oslo.service (assumed to be openstack related)
>> python-oslo.utils (assumed to be openstack related)
>> python-tenacity (has rdeps, cruft)
>>
>> There are also indirect reverse dependencies, (i'm not investigating
>> reverse dependencies of packages that are clearly openstack specific here)
>>
>> python-coloredlogs (via python-humanfriendly, no reverse dependencies)
>> python-datalad (via python-fasteners, no reverse dependencies)
>> duplicity (via python-fasteners)
>> python-oauth2client (via python-fasteners)
>> python-oslo.concurrency (via python-fastners, openstack related)
>> python-taskflow (via python-fasteners, cruft)
>> python-tooz (via python-fasteners, openstack related, cruft)
>> python-googleapi (via python-oauth2client)
>> python-pypowervm (via python-taskflow, openstack related, cruft)
>> python-googleapi-samples (via python-googleapi)
>> python-etcd3gw (no rdeps)
>> python-gnocchiclient (openstack related, cruft)
>>
>> If we ignore openstack stuff, python modules and an examples package the
>> two main packages left seem to be oz and duplicity, oz seems to have
>> very low popcon, but duplicity seems to have a popcon of around 3000 and
>> growing.
>>
>> So the main question seems to be can duplicity be reasonably migrated to
>> python 3 and if not is it worth reinstating the python-monotonic binary
>> package to save duplicity?
>
> What happened is that I simply uploaded the latest version of OpenStack
> from Experimental to Sid. This includes monotonic. It's been a long time
> I maintain monotonic because it's used in OpenStack, then other packages
> started using it. You may have noticed that it was in Experimental with
> Python 2 removed for at least 6 months, just like for Django, giving the
> sign that Py2 would soon go away. However, maybe bugs should have been
> filled, sorry that I didn't do it in time.
>
> Let's take a look at the situation.
>
> As per Andrey's reply, we can fix duplicity.
>
> From your report above, if I remove all the OpenStack stuff (which at
> this time, should all be only Python 3), the only affected packages
> would be:
>
>> python-humanfriendly (has rdeps)
>> oz (rc bug filed #933509)
>> python-coloredlogs (via python-humanfriendly, no reverse dependencies)
>> python-datalad (via python-fasteners, no reverse dependencies)
>> duplicity (via python-fasteners)
>> python-oauth2client (via python-fasteners)
>> python-googleapi-samples (via python-googleapi)
>
> According to the setup.py of python-googleapi in the Github repo, latest
> upstream version supports Python 3, so it should be doable to upload a
> new version to fix this.
>
> I will remove Python 2 suport from python-oauth2client and
> python-fasteners tomorrow.
>
> So, this leaves us only: humanfriendly, oz, python-coloredlogs,
> python-datalad. I've uploaded humanfriendly and coloredlogs Py2 removal.
> BTW, I believe python-coloredlogs was there as a build-depends of
> cyvcf2, which has been fixed on the 1st of august by Andreas Tille.
>
> By all means, let's not play the dance of re-introducting Python 2 when
> we can move forward on the right direction.
>
> Thanks for taking the time to investigate this, this is very useful, and
> I have to admit that, even though I know how to do the work, I am a bit
> lost into knowing from were to begin. The release tracker is not very
> helpful in this regard.
>
> Cheers,
>
> Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Thomas Goirand-3
In reply to this post by peter green-2
On 8/13/19 12:38 PM, peter green wrote:
> python-fasteners (has rdeps)
> python-oauth2client (via python-fasteners)

FYI, I removed Python 2 support from these 2 today! :)

Hopefully, Laszlo Boszormenyi (GCS) will do the work for googleapi, and
then we'll get another chain of Py2 removed. :)

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Thomas Goirand-3
In reply to this post by peter green-2
On 8/13/19 3:30 PM, peter green wrote:
> IMO python-monotonic should be reinstated until it's reverse
> dependencies are sorted out.

There's now only oz, googleapi and duplicity. The last 2 both have Py3
support upstream in a newer version. Let's fix these, as I fixed all the
rest already. If nobody does the work for googleapi and duplicity, ping
me and I'll do it.

While I do agree it's preferable to do things in order, without breaking
things, I very much prefer if we move forward, toward removing Py2,
rather than backward.

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Thomas Goirand-3
In reply to this post by Simon Josefsson-2
On 8/13/19 9:58 PM, Simon Josefsson wrote:
> Once python3-m2crypto is in Debian, I will port oz to python3.
>
> /Simon

Well, it's in unstable already...

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Investigating the reverse dependencies of python-monotonic.

Simon Josefsson-2
Thank you! I just uploaded oz with python 3 dependencies. If any python Debian packager want to take a look and suggest improvements that would be great, as I’m mostly guessing how to package python apps in Debian.

/Simon

> 14 aug. 2019 kl. 09:20 skrev Thomas Goirand <[hidden email]>:
>
>> On 8/13/19 9:58 PM, Simon Josefsson wrote:
>> Once python3-m2crypto is in Debian, I will port oz to python3.
>>
>> /Simon
>
> Well, it's in unstable already...
>
> Thomas Goirand (zigo)