Add a macro for use of build and installer

[s-t-e-v-e-n-k]

Python 3.12 is on the horizon, and will remove the distutils module, which means setup.py install, which is already deprecated, will stop working entirely -- however, if Jason decides to remove it early in a new setuptools release, he can. This impacts us quite a lot, since the %python_install macro calls it.

Use of the installer module would seem to solve a lot of our problems here, but firstly, it will only install wheels, and secondly, %python_build builds eggs, not wheels.

I am proposing we add two macros, I'm not 100% sold on the names yet, but probably %python_wheel_build and %python_wheel_install that will leverage the build module and installer to perform the tasks that the existing macros perform. This issue is not about removing the existing macros.

This will also require BuildRequires changes of course, but also may drop setuptools out of Ring 1, which would be nice. Further more, this does not involve touching the existing %pyproject_wheel and %pyproject_install macros that leverage pip.

Thoughts? Opinions?

[bnavigator]

• Setuptools already overrides/vendors the stdlib distutils and will continue to do so even for Python 3.12 https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html#porting-from-distutils
• setup.py install is independent of distutils unless the packaged setup.py specifically imports it. Even python3 -m build will be affected from a distutils drop if all it does is to use the setuptools backend as defined in the pyproject.toml which in turn calls setup.py
• The fact that setuptools is still the go to backend for many PEP517 builds will never allow us to drop it from Ring 1.
• What's the advantage of a new set of macros over just using %pyproject_wheel and %pyproject_install? Pip is and will continue to be packaged in Ring1 and has a small external dependency footprint.

[s-t-e-v-e-n-k]

• setup.py install is still deprecated, regardless, so we need to do something.
• Never say never, I still remain hopeful that will happen at some point, and Jason does seem to be working towards that goal.
• Pip is enormous and its small external footprint is only because it continues to vendor a lot of other code, which also means it gets a lot more fun to debug issues with calling it. build and installer are targetted, and since both are pypa-sponsored, I remain hopeful that pip itself will use them in the future.

[bnavigator]

• setup.py install is still deprecated, regardless, so we need to do something.

Agreed, but the addition macros for build and installer is orthogonal to this something. You have to replace the calls in the packages, either through replacing %python_build and %python_install or through redefining them. In almost all python package updates I submitted in the past few weeks, I replaced them with the %pyproject_* equivalents and added pip and wheel.

• Pip is enormous and its small external footprint is only because it continues to vendor a lot of other code, which also means it gets a lot more fun to debug issues with calling it. build and installer are targetted, and since both are pypa-sponsored, I remain hopeful that pip itself will use them in the future.

True, but it is still the de facto standard and supported by 99,9% of upstream packages.

[s-t-e-v-e-n-k]

I'm bringing this up again because the dependency cycles are getting ridiculous. Sure, we can use pip and the existing macros, but the bootstrapping is awful, and we now have hatchling which is used by a large number of packages unable to build itself because it's now in a build loop with trove-classifiers.

[mcepl]

If we are talking just about adding yet another macroised way how to build and install Python packages, then I am all for it: more and merrier! It will also mean that build (and installer?) get to the Ring0, but hopefully these would be small ones.

[bnavigator]

we now have hatchling which is used by a large number of packages unable to build itself because it's now in a build loop with trove-classifiers.

In what way does this relate to additional macros and the usage of build and installer instead of pip?

[s-t-e-v-e-n-k]

In what way does this relate to additional macros and the usage of build and installer instead of pip?

Because bootstrapping is a concern here -- pyproject_wheel does not just require pip and everything is golden, hatchling and poetry are also required in larges part of the archive. The build cycle I'm trying to solve is this one:

Cycles for x86_64 (#4) python-hatch_vcs, python-hatchling, python-iniconfig, python-trove-classifiers

build and installer can be bootstrapped by flit_core, which means I'd prefer to switch these packages in particular to using the new macros, if we are in agreement.

[bnavigator]

Still, the bootstrap problem is independent of the the question whether you use build or pip as PEP517 frontend.

[s-t-e-v-e-n-k]

You still seem against adding a macro, so do I close this, or continue arguing?

[bnavigator]

I am mainly against conflating two totally different issues.

• It does not solve the dependency cycle problem
• More macros means more complexity for packagers: How to decide which one to use?
  • Does adding yet another macro group add any benefit?
  • What's the advantage over replacing pip in %pyproject_wheel and %pyproject_install?
  • Compare Fedora: The still use pip in pyproject-rpm-macros

[mcepl]

What's the advantage over replacing pip in %pyproject_wheel and %pyproject_install?

A little +1 from me here. We don’t say %pip_build here, so theoretically it should not matter what tools we use behind the curtains. Yes, complete rebuild of Factory with new macro will be … interesting … but it seems to me like that it is doing the right thing, instead of just the easy one.

[s-t-e-v-e-n-k]

We already have 2 macros for building and installing and 3 macros for testing. But I'm done arguing.