* Python 2 retirement — what should Guix do?
@ 2018-06-16 18:01 Leo Famulari
2018-06-16 18:30 ` Nils Gillmann
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Leo Famulari @ 2018-06-16 18:01 UTC (permalink / raw)
To: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 18:01 Python 2 retirement — what should Guix do? Leo Famulari
@ 2018-06-16 18:30 ` Nils Gillmann
2018-06-16 20:42 ` Pjotr Prins
2018-06-16 21:01 ` Ricardo Wurmus
2018-06-17 14:13 ` Konrad Hinsen
2 siblings, 1 reply; 8+ messages in thread
From: Nils Gillmann @ 2018-06-16 18:30 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 18:30 ` Nils Gillmann
@ 2018-06-16 20:42 ` Pjotr Prins
2018-06-16 21:08 ` Pjotr Prins
0 siblings, 1 reply; 8+ messages in thread
From: Pjotr Prins @ 2018-06-16 20:42 UTC (permalink / raw)
To: Leo Famulari, guix-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 18:01 Python 2 retirement — what should Guix do? Leo Famulari
2018-06-16 18:30 ` Nils Gillmann
@ 2018-06-16 21:01 ` Ricardo Wurmus
2018-06-17 21:15 ` Ludovic Courtès
2018-06-17 14:13 ` Konrad Hinsen
2 siblings, 1 reply; 8+ messages in thread
From: Ricardo Wurmus @ 2018-06-16 21:01 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 20:42 ` Pjotr Prins
@ 2018-06-16 21:08 ` Pjotr Prins
0 siblings, 0 replies; 8+ messages in thread
From: Pjotr Prins @ 2018-06-16 21:08 UTC (permalink / raw)
To: Pjotr Prins; +Cc: guix-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 18:01 Python 2 retirement — what should Guix do? Leo Famulari
2018-06-16 18:30 ` Nils Gillmann
2018-06-16 21:01 ` Ricardo Wurmus
@ 2018-06-17 14:13 ` Konrad Hinsen
2 siblings, 0 replies; 8+ messages in thread
From: Konrad Hinsen @ 2018-06-17 14:13 UTC (permalink / raw)
To: Leo Famulari, guix-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-16 21:01 ` Ricardo Wurmus
@ 2018-06-17 21:15 ` Ludovic Courtès
2018-06-18 7:45 ` Pjotr Prins
0 siblings, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2018-06-17 21:15 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Python 2 retirement — what should Guix do?
2018-06-17 21:15 ` Ludovic Courtès
@ 2018-06-18 7:45 ` Pjotr Prins
0 siblings, 0 replies; 8+ messages in thread
From: Pjotr Prins @ 2018-06-18 7:45 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-06-18 7:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-16 18:01 Python 2 retirement — what should Guix do? Leo Famulari
2018-06-16 18:30 ` Nils Gillmann
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
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.