Re: [gentoo-portage-dev] The build system (and install layout) of Portage
On 3/17/22 10:22, Michał Górny wrote: Hi, everyone. You've probably had the opportunity to hear that a lot has changed in Python packaging since Portage's setup.py was written in 2014. There were some minor changes to keep it working since but it's time to reconsider. Long story short, distutils is strongly deprecated, setuptools deprecated most of the customizations (and we're relying heavily on customizations), PEP 517 doesn't cover our use cases exactly... and it's quite likely that sooner or later our build system will fall apart. On top of that, setuptools is going through a stage of "let's vendor a new dependency every week", so it doesn't look like a feasible long-term solution. A large part of the problem is that Portage is heavily relying on non-Pythonic idioms for installing stuff. I wonder if we can rely less on the deprecated customizations somehow. For example, the venv_data_files function in setup.py succeeds in installing a bunch of files in custom locations, and maybe we can rely more on that approach (use it not only for venv installations). -- Thanks, Zac OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-portage-dev] The build system (and install layout) of Portage
On Thu, 2022-03-17 at 20:57 +, James Le Cuirot wrote: > On Thu, 2022-03-17 at 18:22 +0100, Michał Górny wrote: > > An alternative is to go back to using (at least partially) Makefiles or > > Meson. However, that would have the important drawback that we'd lose > > the ability to install Portage as a regular Python package (e.g. inside > > a virtualenv). > > What is the use case for doing that? I thought maybe testing, but then you can > run Portage and its unit tests in-place without installing it at all right > now. Using Portage as a library for package inspection, etc. -- i.e. mostly CI purposes. -- Best regards, Michał Górny
Re: [gentoo-portage-dev] The build system (and install layout) of Portage
On Thu, 2022-03-17 at 18:22 +0100, Michał Górny wrote: > An alternative is to go back to using (at least partially) Makefiles or > Meson. However, that would have the important drawback that we'd lose > the ability to install Portage as a regular Python package (e.g. inside > a virtualenv). What is the use case for doing that? I thought maybe testing, but then you can run Portage and its unit tests in-place without installing it at all right now. signature.asc Description: This is a digitally signed message part
