1 |
Hi, everyone. |
2 |
|
3 |
You've probably had the opportunity to hear that a lot has changed |
4 |
in Python packaging since Portage's setup.py was written in 2014. There |
5 |
were some minor changes to keep it working since but it's time to |
6 |
reconsider. |
7 |
|
8 |
Long story short, distutils is strongly deprecated, setuptools |
9 |
deprecated most of the customizations (and we're relying heavily |
10 |
on customizations), PEP 517 doesn't cover our use cases exactly... |
11 |
and it's quite likely that sooner or later our build system will fall |
12 |
apart. On top of that, setuptools is going through a stage of "let's |
13 |
vendor a new dependency every week", so it doesn't look like a feasible |
14 |
long-term solution. A large part of the problem is that Portage is |
15 |
heavily relying on non-Pythonic idioms for installing stuff. |
16 |
|
17 |
At this point, I'd love to use flit for Portage, as that's a nice build |
18 |
system with upstream that understands packagers. I mean, if someone |
19 |
tells me they want to avoid vendoring stuff *and* creating cyclic |
20 |
dependencies (all other Python build systems vendor tons of stuff right |
21 |
now), then I can't but appreciate that very much. That said, I don't |
22 |
think flit is powerful enough to handle all the intricacies Portage |
23 |
requires, starting with the fancy way it's installing scripts to many |
24 |
different directories. |
25 |
|
26 |
An alternative is to go back to using (at least partially) Makefiles or |
27 |
Meson. However, that would have the important drawback that we'd lose |
28 |
the ability to install Portage as a regular Python package (e.g. inside |
29 |
a virtualenv). |
30 |
|
31 |
At this point, I've pretty much lost all motivation to work on it. |
32 |
Nevertheless, it's something that needs to be done eventually. Does |
33 |
anyone have some idea, motivation and will to transition Portage to |
34 |
another build system? |
35 |
|
36 |
-- |
37 |
Best regards, |
38 |
Michał Górny |