Hi Lars<br><br>Apologies for the delayed response (meant to earlier), top posting, and the formatting. The reason for all three is that I'm currently away from a proper computer for a few weeks but I'll be back at the beginning of June and can start hacking away then. Of course, happy to be beat to the job or have anything to build off of.<br><br>I'm not sure of any other deep python breakages, but definitely something to look at for the python branch. Although I'm not python expert, especially at packaging, I should probably add myself to the team when I'm back as well.<br><br>Thanks for the details and information, that's very helpful and sounds like a roadmap to have a clean and updated toolchain here.<br><br>John<br>-------- Original Message --------<br>On May 8, 2023, 3:44 PM, Lars-Dominik Braun < lars@6xq.net> wrote:<blockquote class="protonmail_quote"><br>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

</div>