Build has a circular dependency on tomli.

It seems we have a circular dependency issue with build preventing bootstrapping a pep517 toolchain if using the latest version of tomli.

I’m seeing the following dependency cycles here preventing me from using the latest tomli with build:

build -> pep517 -> tomli -> build(needed for building pep517 packages like tomli)
build -> tomli -> build(needed for building pep517 packages like tomli)

I think the solution is to probably have both pep517 and build vendor tomli, although maybe only pep517 needs to vendor it.

[FFY00]

It’s very different from how we do GCC bootstrapping from what I can tell, which is an extremely complex multi-stage process and it’s also very GCC specific.

I guess your mileage might vary, but I maintain 6 GCC toolchains in Arch Linux, so I do have some experience there, and I would describe this process as following the same model overall. Similarly to GCC, we are building a bootstrapping version of the required tooling and then using that to build the actual tooling we want to distribute. GCC is even more complex as it requires building a libc with the bootstrapping version and then rebuilding itself against the libc that was built.

Which is a huge pain(also potentially slows down builds a lot) and totally unnecessary from a technical point of view here.

I do not disagree that it’s a huge pain. You can make whatever technical review of this that you want, but if your solution includes opening bugs in the upstreams asking for them to change to fit your model, then you need to accept that that might not happen. I understand that you have experience with packaging and bootstrapping, and respect that, but so do we, and unless we’ve failed to properly consider your specific use-case (which after our extensive discussion, I assure I did not), you need to respect that we are the ones maintaining the software and after considering all the use-cases we need to support, maintenance costs, and social costs, we have made our call.

[FFY00]

That approach is problematic since the submodule deps don’t seem to be namespace vendored so they would potentially conflict with the normal versions of those packages.

The idea is that you build bootstrapping versions of these packages and then use them to build the proper versions you want to distribute. You surely need to do the same with GCC for eg., this is a perfectly standard bootstrapping procedure. It would be great to be able to avoid it, but we are stuck with this for now.