Python 2 retirement — what should Guix do?

Python 2 retirement — what should Guix do?

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 905 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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.

Re: Python 2 retirement — what should Guix do?

[Pjotr Prins]

The move from Python2 to Python3 will go into the history books as one
hugely mismanaged transition - call it a first order screw up. The
cost to the community is enormous, if I go by the hours I personally
already spent on managing the issue! And that just for the sake of a
few (minor) syntax changes and a new API for C extensions.

Not even the Ruby guys fucked up so badly with the transition to 2.0!
And that was bad enough. Especially the change in behaviour of Proc.

Guix is actually one of the best tools to manage the transition. I
love it for that. I don't think we should keep supporting both Python
2 and 3 versions of modules by default when the time comes. People
will do that when they need to.  I will. But we can certainly ease the
transition at little cost (to us).

So, Leo, +1 from me.

Pj.

Re: Python 2 retirement — what should Guix do?

[Ricardo Wurmus]

Hi Leo,

> Presumably, Python 2 will be maintained by some third parties for quite
> a while after 2020.

If that is so, it’s probably fine to keep a “python2” package.

> 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.

I agree.  My preference is to build Python 2 packages only when
absolutely needed by another package.

It’s possible that this will be a non-negligible number of packages
(some bioinfo tools developed in 2018 come to mind…), but I don’t want
us to artificially extend the lifespan of an unmaintained language.

--
Ricardo

Re: Python 2 retirement — what should Guix do?

[Pjotr Prins]

On Sat, Jun 16, 2018 at 10:42:43PM +0200, Pjotr Prins wrote:
> Not even the Ruby guys fucked up so badly with the transition to 2.0!
> And that was bad enough. Especially the change in behaviour of Proc.

Actually it was the transition from 1.8 to 1.9 where many gems were
incompatible because of block scoping changes. Proc was part of that
and where my gems had most problems ;). This was around 2008 and it
took a few years befor 1.9 became the standard and most had moved
across. But I still have some code that runs on 1.8 only. That is why
Guix has

  https://hydra.gnu.org/job/gnu/master/ruby-1.8.7-p374.x86_64-linux

Even though it has hardly any supporting modules in Guix.  Is that not
great? I think it is. Try and run Ruby 1.8.7 on most other
distributions today.

For Python2 we also have some C modules that are just not worthwhile
porting to Python3. Mostly because we are the only ones using them! It
it would take person months migrating them. We'll just live with those
and run them as external Python2 processes from Python3. That is
pretty OK even if it does not win points for beauty.

Pj.

Re: Python 2 retirement — what should Guix do?

[Konrad Hinsen]

Leo Famulari <leo@famulari.name> writes:

> 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.

I expect Python 2 to be widely used for a few years longer. In my
environment (computational chemistry), there is still a lot of Python 2
code in use that is too expensive to port to Python 3 (mainly because of
C modules). Most people seem to expect that life will go on like before,
not worrying about the end of support for Python 2 at all. The few who
do are making plans for running their Python 2 code in sandboxed
environments.

Guix is one of the best tools to manage this legacy code, so I hope
Python 2 will stay in for those packages that need it. But the general
policy of having both for all packages can certainly be softened without
much loss.

Konrad.

Re: Python 2 retirement — what should Guix do?

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

> I agree.  My preference is to build Python 2 packages only when
> absolutely needed by another package.

“python2-” packages are mostly a convenience for users who’d like to use
them directly.  For applications, ‘package-with-python2’ takes care of
“converting” complete DAGs to Python 2, so those “python2-” packages
don’t matter much.

It seems too early to get rid of everything Python 2, as Konrad
suggested.

Softening the policy to add “python2-” packages sounds like a good way
to move forward.  For new packages, it’s quite simply: just don’t
provide the “python2-” variant unless it’s required.  For existing
packages, it seems trickier though.  Which packages would we remove and
when?

Thanks,
Ludo’.

Re: Python 2 retirement — what should Guix do?

[Pjotr Prins]

On Sun, Jun 17, 2018 at 11:15:36PM +0200, Ludovic Courtès wrote:
> Softening the policy to add “python2-” packages sounds like a good way
> to move forward.  For new packages, it’s quite simply: just don’t
> provide the “python2-” variant unless it’s required.  For existing
> packages, it seems trickier though.  Which packages would we remove and
> when?
 
When they break and no one is interested in fixing. As long as there
is interest there will be fixers.

Pj.