| 1 |
On 3/17/22 10:22, Michał Górny wrote:
|
| 2 |
> Hi, everyone. |
| 3 |
> |
| 4 |
> You've probably had the opportunity to hear that a lot has changed |
| 5 |
> in Python packaging since Portage's setup.py was written in 2014. There |
| 6 |
> were some minor changes to keep it working since but it's time to |
| 7 |
> reconsider. |
| 8 |
> |
| 9 |
> Long story short, distutils is strongly deprecated, setuptools |
| 10 |
> deprecated most of the customizations (and we're relying heavily |
| 11 |
> on customizations), PEP 517 doesn't cover our use cases exactly... |
| 12 |
> and it's quite likely that sooner or later our build system will fall |
| 13 |
> apart. On top of that, setuptools is going through a stage of "let's |
| 14 |
> vendor a new dependency every week", so it doesn't look like a feasible |
| 15 |
> long-term solution. A large part of the problem is that Portage is |
| 16 |
> heavily relying on non-Pythonic idioms for installing stuff. |
| 17 |
|
| 18 |
I wonder if we can rely less on the deprecated customizations somehow.
|
| 19 |
For example, the venv_data_files function in setup.py succeeds in
|
| 20 |
installing a bunch of files in custom locations, and maybe we can rely
|
| 21 |
more on that approach (use it not only for venv installations).
|
| 22 |
--
|
| 23 |
Thanks,
|
| 24 |
Zac |
Archives