HI Maxim, Thanks for your answer.
On Fri, 29 Jan 2021 at 04:49, Maxim Cournoyer <[email protected]> wrote: > zimoun <[email protected]> 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
