I’m writing a build-backend foobar that also builds itself using the in-tree build-backends. To pull in all of foobar’s dependencies for the build, I simply require foobar as a build dependency (although I actually only need its dependencies here).
I have the impression that you are not supposed to list foobar in build-system.requires if you are building foobar (for the time being, PEP 517 mandates no cyclic dependencies for build-system.requires). This would remove the part of the work flow that you add an entry then remove an entry, but it would not solve the boring part of double-bookkeping dependencies in 2 places.
To solve this problem without having to wait for changes in the standards, you have a few options.
One way for example would be to remove the build-system.requires, but use the get_requires_for_* hook to return the dependencies dynamically (and then you can read them from wherever place they are written).
Another way would be removing project.dependencies, but listing dependencies im dynamic. Then again you can get read the dependencies from wherever place you like when writing the METADATA or PKG-INFO files.
Note however, that these mechanisms would require you to “special case” somehow the process to bootstrap your own backend.
Without special-casing, the only thing that I can think about is to have an intermediate meta-package that list all the dependencies. This way you just have to list one entry in build-system.requires and project.dependencies. This however is not very ergonomic during development.