[bug#63139] [PATCH python 02/20] gnu: Add python-pyproject-hooks.

[Lars-Dominik Braun]

Hi,

> From what I remember and
> thought, the newer python-pypa-build needs python-pyproject-hooks.
> Which itself would be built with pyproject-build-system, creating a
> circular dependency.

ah, yes, you’re right. For some reason the current
pyproject-build-system differs from my original proposal and bundles
python-pypa-build in python-toolchain (even though it is not used). As
we can see from this example doing so is a very very bad idea (because
it leads to cycles).

> But, I don't know anything about flit_core and
> that system. So you are saying flit_core is used to build each of
> these without a cycle then?
> Can you layout what the new structure would be for updating
> python-pypa-build with python-pyproject-hooks then? (And then
> deprecate pep517.)

In theory that would be possible if python-toolchain did not depend on
pypa-build. Looking at the respective pyproject.toml files flit-core
is entirely self-contained and can be built using itself. Then you can
build pyproject-hooks, packaging and tomli using flit-core. And then
pypa-build can be built using flit-core and all of the previous packages
as dependencies. poetry-core is also self-contained and can be built
without any dependencies (and the full poetry should never be required
to build any project, but obviously packages in Guix use it for that
purpose -.-). But none of this is really necessary, because – again
– pypa-build is not used by pyproject-build-system.

So I propose the following:

- Create a python-team branch.
- Use python-sans-pip-wrapper as default-python in pyproject-build-system,
  like I originally proposed and add python-setuptools/python-wheel
  where necessary.
- Implement backend-path in pyproject-build-system, so we can bootstrap
  flit-core/poetry-core/… properly.
- Expose ensure-no-mtimes-pre-1980 (#63044).
- Finally fix python-yubikey-manager.

Anything else that’s broken right now?

Cheers,
Lars