Gentoo Archives: gentoo-project

From: R0b0t1 <r030t1@×××××.com>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] For next council meeting: moving Portage to python3.6+
Date: Sat, 24 Feb 2018 17:55:13
Message-Id: CAAD4mYja_TXXkvC4uTFtTa3i5Eqx685e-6+og1ZpAZtkF8Lmuw@mail.gmail.com
In Reply to: Re: [gentoo-project] For next council meeting: moving Portage to python3.6+ by "Michał Górny"
1 On Sat, Feb 24, 2018 at 2:57 AM, Michał Górny <mgorny@g.o> wrote:
2 > W dniu pią, 23.02.2018 o godzinie 19∶58 -0700, użytkownik Daniel Robbins
3 > napisał:
4 >> Hi there,
5 >>
6 >> Zac Medico and I would like to discuss the following at the next council
7 >> meeting: moving Portage to support only python3.6+. One of the primary
8 >> benefits of this change is that it will allow us to use python's native
9 >> async implementation as we look to make Portage faster at a critical time
10 >> when we are looking to improve Portage performance. As we approach the
11 >> stabilization of python3.6 in Gentoo, it seems like a good time to discuss
12 >> the process of jettisoning 2.7 support and standardizing on 3.6 for Portage.
13 >>
14 >> Right now, a custom 'asyncio-like' set of classes is used for async in
15 >> Portage. This limits interoperability with other async-friendly python
16 >> modules and produces additional maintenance overhead for the project.
17 >>
18 >> Maybe even more importantly, 3.6+ compatibility also gives us the ability
19 >> to use many other new language features and reduce the maintenance overhead
20 >> of having 2.7 compatibility for the extensive Portage code-base. We expect
21 >> that this will improve the velocity of Portage development, provide
22 >> opportunities to improve Portage functionality and also allow us clean up a
23 >> lot of unnecessarily complex code (and eliminate code) that is there only
24 >> to ensure compatibility with 2.7.
25 >>
26 >
27 > This is Portage's team decision. The Council has already voted on for
28 > how long upgrade path needs to provided (that was 2 years, I think)
29 > and what Portage developers decide beyond that is up to them.
30 >
31 > I personally don't have anything against removing support for Python 2
32 > (though I think many users would do). However, I wouldn't go up to 3.6+
33 > at once, especially if 3.5 is the current version we are using. Even if
34 > we switch the default, I think it'd be reasonable to provide a lengthy
35 > grace period not to make upgrading Portage PITA.
36 >
37
38 I am a stain upon this mailing list and my opinion is of no
39 consequence, but I think moving directly to 3.6 would be the best
40 option. Python 3.5 is a very strange situation and has some half
41 finished features despite being a full release. It is very likely the
42 release of 3.6 was rushed to fix some of what was "wrong" in 3.5
43 (mainly missing async features, but there are many).[1] These new
44 features are useful enough that they will likely outweigh any
45 additional work involved in adopting 3.6.
46
47 Python 2.7 will still be necessary for some hardened utilities, from memory.
48
49 Cheers,
50 R0b0t1
51
52
53 [1]: https://docs.python.org/3/whatsnew/3.6.html

Replies

Subject Author
Re: [gentoo-project] For next council meeting: moving Portage to python3.6+ Daniel Robbins <drobbins@××××××.org>