Currently, it's not possible to install a Coherent System package from a directory or git source because the pyproject.toml doesn't exist (and is written on demand by coherent.build and coherent.test).
The reason the pyproject.toml doesn't exist is because it becomes static boilerplate manifest in every project instead of the template managed by the system.
I'd like to find a way to support installation from such sources. I can imagine a few approaches:
Provide an explicit installer
Alongside the build and test commands, the system could provide an install command, which would need to wrap or re-implement parts of pip to allow the various stages to take place (download/clone, copy to temp build dir, (inject pyproject.toml), complete the steps of the build, then cleanup).
Provide a patched pip
Instead of having a installer wrapper, coherent could provide a customized/forked version of pip that's aware of coherent projects.
Native support in pip
It's conceivable that pip (or other popular installers) could be enhanced with functionality to recognize coherent system packages and infer the build backend.
A customization option available to pip
Pip could honor a new environment variable, something like PIP_INSTALL_DEFAULT_BACKEND=coherent.build (and possibly a similar variable for declaring the dependencies PIP_INSTALL_DEFAULT_BUILD_REQUIRES=coherent.build) that would cause pip to override the default backend (instead of setuptools.build_meta.__legacy__).
Capitulate to the standard
Maybe coherent.build should compromise its principled stance against static metadata and require each and every project to include the three-line pyproject.toml.
Currently, it's not possible to install a Coherent System package from a directory or git source because the
pyproject.tomldoesn't exist (and is written on demand bycoherent.buildandcoherent.test).The reason the pyproject.toml doesn't exist is because it becomes static boilerplate manifest in every project instead of the template managed by the system.
I'd like to find a way to support installation from such sources. I can imagine a few approaches:
Provide an explicit installer
Alongside the
buildandtestcommands, the system could provide aninstallcommand, which would need to wrap or re-implement parts of pip to allow the various stages to take place (download/clone, copy to temp build dir, (inject pyproject.toml), complete the steps of the build, then cleanup).Provide a patched pip
Instead of having a installer wrapper, coherent could provide a customized/forked version of pip that's aware of coherent projects.
Native support in pip
It's conceivable that pip (or other popular installers) could be enhanced with functionality to recognize coherent system packages and infer the build backend.
A customization option available to pip
Pip could honor a new environment variable, something like
PIP_INSTALL_DEFAULT_BACKEND=coherent.build(and possibly a similar variable for declaring the dependenciesPIP_INSTALL_DEFAULT_BUILD_REQUIRES=coherent.build) that would cause pip to override the default backend (instead ofsetuptools.build_meta.__legacy__).Capitulate to the standard
Maybe coherent.build should compromise its principled stance against static metadata and require each and every project to include the three-line pyproject.toml.