all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nils Gillmann <ng0@n0.is>
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org
Subject: Re: Python 2 retirement — what should Guix do?
Date: Sat, 16 Jun 2018 18:30:55 +0000	[thread overview]
Message-ID: <20180616183055.kal6urc6srrn7ikl@abyayala> (raw)
In-Reply-To: <20180616180118.GA9585@jasmine.lan>

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.

  reply	other threads:[~2018-06-16 18:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-16 18:01 Python 2 retirement — what should Guix do? Leo Famulari
2018-06-16 18:30 ` Nils Gillmann [this message]
2018-06-16 20:42   ` Pjotr Prins
2018-06-16 21:08     ` Pjotr Prins
2018-06-16 21:01 ` Ricardo Wurmus
2018-06-17 21:15   ` Ludovic Courtès
2018-06-18  7:45     ` Pjotr Prins
2018-06-17 14:13 ` Konrad Hinsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180616183055.kal6urc6srrn7ikl@abyayala \
    --to=ng0@n0.is \
    --cc=guix-devel@gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.