Yeah, I forgot about the option of delegating the details of the technical specification to “What os.path does” rather than having to spell them out explicitly - that does indeed make things a lot simpler when it comes to allowing paths inside the repo as config options, since the hard part has already been done for us.
I’m still wary of encouraging folks to add multiple arbitrary subdirectories to the execution environment of their build backend though - that’s really the sort of thing the build backend should be handling, and that degree of flexibility isn’t needed just to solve the bootstrapping problem.
That said, I also think there’s virtue in the conceptual simplicity of adding an extra directory to sys.path. Yes, there are alternative ways to load a module that don’t require that, but they all come with caveats and quirks as to what kinds of imports will actually work from the loaded module
As such, my next iteration on my previous proposal would be to blend it with the “arbitrary additions to sys.path” idea, and allow a single additional entry, using a name that makes the intended use of the feature clear:
[build-system]
requires = []
build-backend = "setuptools.build_meta"
backend-bootstrap-location = "."
(Note: the location part of the name was inpired by importlib — The implementation of import — Python 3.12.1 documentation, since we adopted the “filesystem location” phrasing to avoid the ambiguity between “filesystem path” and “import path”)
Such a setting would be enough to allow setuptools and other projects to bootstrap themselves, and would mean that flit wouldn’t need the intreehooks helper any more. It’s also compatible with backends that use a src directory layout:
[build-system]
requires = []
build-backend = "some_backend.build_hooks"
backend-bootstrap-location = "src"
If a particular backend wanted to disallow the use of backend-bootstrap-location for projects other than itself (by finding that entry on sys.path and removing it before running any project supplied code), then that would be entirely OK. It would also be fine for backends to warn about the erroneous usage when building from source (that would be a decision for the backend authors to make).