Re: Python 2 retirement — what should Guix do?

[Nils Gillmann]

Leo Famulari transcribed 1.9K bytes:
> In 2020, Python 2 will no longer be supported by the Python team. [0]
> 
> To quote Guido van Rossum, "The way I see the situation for 2.7 is that
> EOL is January 1st, 2020, and there will be no updates, not even
> source-only security patches, after that date. Support (from the core
> devs, the PSF, and python.org) stops completely on that date." [1]
> 
> In Guix we aim to offer software that is safe to use, which typically
> means "maintained".
> 
> Presumably, Python 2 will be maintained by some third parties for quite
> a while after 2020.
> 
> I wonder, what should Guix do?
> 
> Personally, I think our set of Python packages is relatively hard to
> maintain. There is a lot of brittle code in there. I'd be happy to drop
> our policy that Python libraries have both Python 2 and 3 packages by
> default.
> 
> [0]
> https://legacy.python.org/dev/peps/pep-0373/
> 
> [1]
> https://mail.python.org/pipermail/python-dev/2018-March/152348.html


While I agree with the security aspect, I don't think the goal to drop
python-2 by 2020 on OS site is realistic at all.
We can do it, but we will have lots of people out there relying on python-2.
When a language implementation reached EOL, we don't have to follow that.
Personal misery:
I seem (at the moment) to be the only GNUnet dev trying to move whatever
python2 code we have in all projects around and in GNUnet to python2+3
dual support, and that's not even fulltime. 2020 might be doable, but who
knows what life throws at you.
It could be reasonable to do the following:

- Jan 2020. Python drops 2 support.
- Also Jan 2020: we document an emphasis on prefering python3 packages,
  or even the recommendation to help upstream to make the software build
  with python3. If there's nothing special going on, it is rather trivial
  but nevertheless can take some time.
  We keep python-2 around. We announce a feature freeze, starting Jan 2021,
  on the python2 part of python packages which exist in both versions if
  they are build from the same source.
- Jan 2021: We no longer accept python-2 packages unless it is for a specific
  reason, case-by-case decision.
- 2022: Drop python-2?

I'm really in favor of keeping it around but leaving it as a conscious
decision for people who need it. That's what I do for the kernel for
example. I bump versions, I try to maintain the official supported
versions but leave versions and package recipes of older versions
around.
Whoever needs older versions will be aware of the implications that
come with these older versions.

Of course it is really tempting to get to a system which only supports one
implementation of the python language, and thus get rid of some code.
If we were the size of Debian, we could even shape the process and adoption
by option to no longer support the dual scheme. Of course because we are
not the size of Debian, it is also easier to decide what we do. I think
full-time python devs such as Hartmut will have more to say about this.