[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python 2 EOL starts to break packages
From: |
zimoun |
Subject: |
Re: Python 2 EOL starts to break packages |
Date: |
Fri, 29 Jan 2021 11:02:09 +0100 |
HI Maxim,
Thanks for your answer.
On Fri, 29 Jan 2021 at 04:49, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
> Whenever I update a Python package that breaks its Python 2 variant, I
> look at the dependencies of those variants with 'guix refresh -l
> python2-something'. If all the dependents are purely python2 variants
> themselves, then I proceed to remove them all from the package
> collection. If instead some non-python2 variant package
> depends on it, I research if that package could be updated to make it
> Python 3 compatible. If yes, then problem solved. Otherwise we need to
> ping upstream and keep it for a little longer before it gets removed.
By "keep it for a little longer", do you mean update the Python 3
version and explicitly define the Python 2 variant ? Or do you mean do
not update at all?
In other words, should 3142daccbe be reverted? Or should 3142daccbe
keep as it is and the variant 'python2-setuptools' defined explicitly
with the previous version?
Noting that people submitting and reviewing patches should both apply
your methodology. Otherwise, the janitor work is more burden.
Contrary to what I am proposing, i.e., move all the python2-* variants
inside a specific module, where the janitor work can be done
asynchronously: open this module and address package one after the
other, mainly once a while by batch. Instead of greping, etc. I can
tell you by janitoring Bioconductor packages that grepping becomes
really annoying when you address more packages than a child is able to
count. ;-)
In other words, I am proposing to separate update and janitor with an
easier janitor task.
Well, all are fine with me. The aim of my email is simply to roughly
agree on a "way" to collectively ease this boring task.
> The python2-behave-web-api is not a concern (there's an existing
> python-behave-web-api package), but the others are. There's an issue
> about syncthing-gtk reliance on Python 2 at
> https://github.com/kozec/syncthing-gtk/issues/568. For grocsvs I've
> just commented at https://github.com/grocsvs/grocsvs/issues/6. If the
> upstream are not willing to budge, the packages can be removed after a
> grace period (6 months, I'd say).
Just to fix the idea, the last release of syncthing-gtk is from 4 Aug
2019 and the last commit in master from 30 Oct 2019. The issue you
mention is from 30 Nov 2020 but the real first one is #487 [1] from 22
Oct 2018 and mentioning a port to Python 3 by Debian folks [2] (not
tried the status). Hum, the 6 months grace period is far beyond. ;-)
(I am not asking any remove.)
And I guess your are Apteryks that asked to reopen the issue of grocsvs. :-)
Well, since this package is Bioinformatics, I can tell you that it
will not be ported, another story.
However, this Python 2 package had been added in Guix on 2020-05-05,
i.e., post Python 2 EOL. I think it is a "mistake" and instead should
live in the channel "guix-past", but at the time, this channel did not
exist, if I remember correctly.
Anyway, that's a discussion for bug#46132.
Just to understand, does your suggestion is: should the author of
3142daccbe updating python-setuptools have done these 2 checks?
(Maybe more for some cases.)
In my mind, no. And having a separate file containing all the python2
variants ease the review of each and then janitor.
1: https://github.com/kozec/syncthing-gtk/issues/487
2: https://salsa.debian.org/debian/syncthing-gtk/-/tree/python3-port
Cheers,
simon