build: 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.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 31 (31 by maintainers)
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.
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.
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.
I don’t see how any of this is better than doing what @FFY00 suggested with the ‘shadow’ package as demonstrated by https://github.com/FFY00/python-bootstrap. At the end of the day you’re still gonna have to run some part of the stack from path, which currently appears to be flit and the installer.