I don’t think adding a bootstrap mechanism makes it easier to implement a backend compared to blessing the idea that backends can rely on pre-existing wheels. Maintaining a self-bootstrapping backend is complicated, and you have to worry about accidentally getting cycles if you take on any dependencies. By comparison, if you can rely on pre-existing wheels, all you have to do is build a wheel once, then you can rely on the last wheel you built to do your current build.
The only reason
flit needs to use
intreehooks (and thus
setuptools) is because we’ve decided at the moment that
pip install --no-binary :all: as it currently works, should build everything, including build tools, from an
sdist, and that we want
--no-binary :all: to continue working. It’s also the reason
setuptools can’t use PEP 517 at the moment.
If we either decide that breaking
--no-binary :all: is not a big deal or we modify the behavior of
--no-binary :all: so that it will build from a wheel to satisfy self-referential build dependencies or some other solution that involves in “blessing” the fact that backends can rely on a wheel of a previous version existing, it actually becomes much easier to build a backend from source, even if the backend builds itself. The only requirement is that you either use an existing backend to build your first wheel or you do it manually, neither of which is terribly onerous.