guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]