Is it possible to use a local build backend?

We have some efforts here at work to move away from setuptools. I have searched the internet and found enscons which seems to fit our tools pretty well. However, there are a few features missing and since our pull request is pending for some time now, we thought it could be reasonable to have the build backend incorporated in our source tree. Our source tree contains various different python projects which are to be built as wheels.

However, this seems to be non-straightforward unfortunately. I have stumbled across the backend-path but it is only ment for bootstrapping backends (it spits out ValueError: paths must be inside source tree) when being used with relative paths going upwards.

I’m not sure if I’m missing something obvious, but it doesn’t seem to be possible at all to have a build backend which is not installable from pypi or a git dependency like “project @ git+https://github.com/…”? I have tried -e, but this is failing.

If you disable build isolation, and the build environment already has the build backend installed that is specified in pyproject.toml, then it should just work. (Or you can just have it install enscons from PyPI by specifying the build system normally.) It won’t use a “local” (to the machine but not the source tree) backend from an arbitrary location.

In-tree build backend is quite niche as far as I can tell. I do not know of many who have done this before. I know the build backends do it but I do not think it is only meant for bootstrapping backends:

Alternatively, you could always consider publishing your fork on PyPI (or whatever other package index you have available).

Maybe there is something useful in there:

Disabling build isolation is probably incompatible to using a requirements.txt file, since - as I understand it - pip will apply this setting for all packages listed in requirements.txt, even if the build requirements of packages are not fulfilled. That would mean that we have to list our packages which need the local backend seperated from the rest of the dependencies. Might be a possible workaround though not really ideal.

PEP 517 Backend bootstrapping

In this thread it becomes pretty clear that the only use case intended for backend-path is the bootstrapping use case, and indeed there is a check implemented that the backend-path must be relative to the project to be built and going up with specifying ../ paths leads to an exception unfortunately.