search

coherent-oss / system

4 stars 0 forks source link

Provide better install ergonomics #8

Closed jaraco closed 3 months ago

jaraco commented 6 months ago

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.

jaraco commented 3 months ago

In coherent-oss/system#15, we're opting, at least for now, for "Capitulate to the standard" and adding a pyproject.toml to every project.