1 |
On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: |
2 |
> I'm late to the party as usual. Seems upstream plans a final 2.7.18 |
3 |
> security update in April of 2020, then they will consider the 2.7 branch |
4 |
> EOL. They say most of these updates were done in 2019, and so are still |
5 |
> technically sticking to their mantra of no more updates after 01/01/2020. |
6 |
> |
7 |
> PEP 373 covers this: |
8 |
> https://www.python.org/dev/peps/pep-0373/#release-schedule |
9 |
> |
10 |
> """ |
11 |
> Planned future release dates: |
12 |
> |
13 |
> 2.7.18 code freeze January, 2020 |
14 |
> 2.7.18 release candidate early April, 2020 |
15 |
> 2.7.18 mid-April, 2020 |
16 |
> """ |
17 |
> |
18 |
> IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER the |
19 |
> release of 2.7.18. This provides some time for people to transition systems |
20 |
> off of 2.7-dependent packages. |
21 |
> |
22 |
> It might be worthwhile to treat the removal of Python-2.7 from the tree in |
23 |
> the same manner as an EAPI deprecation and removal, given how ingrained it |
24 |
> is due to its longevity. That will minimize the whiplash-effect of emerge |
25 |
> complaining about slot conflicts and dependency conflicts. Like I just ran |
26 |
> into w/ setuptools-45.0.0.0's release. |
27 |
|
28 |
Joshua, |
29 |
|
30 |
I understand that you don't do much Python ebuild work, or probably |
31 |
Python development in general. I understand that you may feel like you |
32 |
need more time with Python 2. But before sending such mails, please try |
33 |
to put yourself in our skin. |
34 |
|
35 |
Imagine I've spend a few hours yesterday merely trying to find |
36 |
a reasonable subset of OpenStack packages that can have Python 2 removed |
37 |
(OpenStack has done Python 3 releases for quite a while already). |
38 |
Believe me, it's not interesting satisfactory work. It's a struggle |
39 |
against neverending conflicts with revdeps, stale stable packages, more |
40 |
indirect revdeps... All that to move a few dozen packages forward |
41 |
and have less pain for end users in the end. |
42 |
|
43 |
Now imagine someone who doesn't really know much about maintaining |
44 |
Python in Gentoo and problems related to Python 2 sunrising, grabs one |
45 |
site about Python releases and tells me what to do without knowing |
46 |
the wider context. Wouldn't you feel angry? Demotivated? Depressed |
47 |
even? |
48 |
|
49 |
I mean, forgive my expression but we're deep in shit. As you've noticed |
50 |
yourself, emerge spews few pages of 'I can't upgrade setuptools' because |
51 |
of humongous number of packages that still need Python 2-capable |
52 |
version. Sure, we could put some effort into making it still work with |
53 |
Python 2, then start collecting more and more patches to various |
54 |
packages just to keep things working. But then, 3-6-12 months from now |
55 |
it will no longer be feasible, the cesspool will overflow and we'll be |
56 |
even deeper in shit that we're today. |
57 |
|
58 |
If people started removing Python 2 from Gentoo years ago, like upstream |
59 |
suggested, today things would be much better. But we waited till last |
60 |
minute. And now you're telling us to wait more because there will be |
61 |
a new release of the *interpreter*? |
62 |
|
63 |
-- |
64 |
Best regards, |
65 |
Michał Górny |