[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python 2 EOL starts to break packages
From: |
Maxim Cournoyer |
Subject: |
Re: Python 2 EOL starts to break packages |
Date: |
Thu, 28 Jan 2021 22:49:13 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi Simon,
zimoun <zimon.toutoune@gmail.com> writes:
[...]
> Removing ’python2-setuptools’ from Guix could break some other packages.
> Maybe? Who knows? ;-)
>
> Instead, a plan could be:
>
> a) move all the ’python2-<package>’ to their own module
> say (gnu packages python2-xyz)
> b) pin the ones which breaks; pin meaning «not use package-with-python2»
> c) fix a deadline announcing the remove of availability at user level
> d) after this date, hide all the python2 packages
> e) remove case per case these hidden python2 packages
I think that's more involved than it needs to be. Here's how I've been
slowly getting at the Python 2 issues:
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.
> Today, it does not make sense to have ’python2-setuptools’ in a manifest
> file or type ‘guix install python2-setuptools’. So it should not be
> possible and raise “package does not exist”. However, I could have a
> custom package that depends on ’python2-setuptools’ so it should be
> accessible via “#:use-modules (gnu packages python2-xyz)”.
Let's apply this to the current case:
$ guix refresh -l python2-setuptools
Building the following 3 packages would ensure 7 dependent packages are
rebuilt: python2-behave-web-api@1.0.6 grocsvs@0.2.6.1-1.ecd956a
syncthing-gtk@0.9.4.4
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).
Does that help?
Maxim