guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the upcoming Great Python2 Purge™


From: Leo Famulari
Subject: Re: the upcoming Great Python2 Purge™
Date: Wed, 26 Dec 2018 23:50:17 -0500
User-agent: Mutt/1.11.0 (2018-11-25)

On Wed, Dec 26, 2018 at 01:30:53PM +0100, Marius Bakke wrote:
> Efraim Flashner <address@hidden> writes:
> > We're now about a year out from the official EOL for python2 (Jan 1,
> > 2020). So far we've been not adding python2 variants of packages that
> > are new unless they're actually needed for something. Do we want to
> > start removing python2 packages when updating other packages if they are
> > leaf packages?
> 
> I think it's okay to start removing "leaf" Python 2 packages.  In most
> cases they were probably never used anyway, or the dependents have
> transitioned to their Python 3 counterparts.
> 
> We'll probably break some channels, but I'm sure our users won't have
> any difficulties adding them back to their own channels if need be.

If we were to start removing Python 2 packages, I like Pjotr's
suggestion that we offer a lengthy grace period to help people set up
some channels to support their work. We don't need to always do this
sort of thing but, in this case, it will be good practice for everyone
involved, and the change is large and well-publicized.

My opinion is that we don't need to start removing them before 2020 and,
even after that, we may choose to use a 3rd-party Python 2 distribution
from someone like Red Hat. Of course, as always, it depends on whether
or not any Guix developers are willing to do the work.

> On a related note, we also have a number of [Python 3] packages that
> have been failing to build for a long time.  Some of these are trivial,
> i.e. what "guix import" produces.
> 
> It would be good to get rid of those as well, as the would-be user is
> much better off starting from "guix import" instead of first getting
> disappointed by the Guix package and then having to go through all the
> trouble of submitting a patch.
> 
> Should we have some sort of policy or threshold for when to remove such
> packages?  Maybe after 3-6 months?

Yes, I agree, there must be some point where we remove packages that
simply don't work at all.

Attachment: signature.asc
Description: PGP signature


reply via email to

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