| 1 |
W dniu pią, 23.02.2018 o godzinie 19∶58 -0700, użytkownik Daniel Robbins |
| 2 |
napisał: |
| 3 |
> Hi there, |
| 4 |
> |
| 5 |
> Zac Medico and I would like to discuss the following at the next council |
| 6 |
> meeting: moving Portage to support only python3.6+. One of the primary |
| 7 |
> benefits of this change is that it will allow us to use python's native |
| 8 |
> async implementation as we look to make Portage faster at a critical time |
| 9 |
> when we are looking to improve Portage performance. As we approach the |
| 10 |
> stabilization of python3.6 in Gentoo, it seems like a good time to discuss |
| 11 |
> the process of jettisoning 2.7 support and standardizing on 3.6 for Portage. |
| 12 |
> |
| 13 |
> Right now, a custom 'asyncio-like' set of classes is used for async in |
| 14 |
> Portage. This limits interoperability with other async-friendly python |
| 15 |
> modules and produces additional maintenance overhead for the project. |
| 16 |
> |
| 17 |
> Maybe even more importantly, 3.6+ compatibility also gives us the ability |
| 18 |
> to use many other new language features and reduce the maintenance overhead |
| 19 |
> of having 2.7 compatibility for the extensive Portage code-base. We expect |
| 20 |
> that this will improve the velocity of Portage development, provide |
| 21 |
> opportunities to improve Portage functionality and also allow us clean up a |
| 22 |
> lot of unnecessarily complex code (and eliminate code) that is there only |
| 23 |
> to ensure compatibility with 2.7. |
| 24 |
> |
| 25 |
|
| 26 |
This is Portage's team decision. The Council has already voted on for |
| 27 |
how long upgrade path needs to provided (that was 2 years, I think) |
| 28 |
and what Portage developers decide beyond that is up to them. |
| 29 |
|
| 30 |
I personally don't have anything against removing support for Python 2 |
| 31 |
(though I think many users would do). However, I wouldn't go up to 3.6+ |
| 32 |
at once, especially if 3.5 is the current version we are using. Even if |
| 33 |
we switch the default, I think it'd be reasonable to provide a lengthy |
| 34 |
grace period not to make upgrading Portage PITA. |
| 35 |
|
| 36 |
This is especially important now that a new EAPI is approaching, |
| 37 |
and we will have to deal with EAPI upgrade path. |
| 38 |
|
| 39 |
-- |
| 40 |
Best regards, |
| 41 |
Michał Górny |
Archives