Given the complexity of the debate in the other thread, which IMO stems out of the vast number of use cases, why not coming back to this proposal? It may be considered somewhat “impure” in the sense that the back-end may undertake some install steps (if any, see below), but it certainly sounds practical to me. Apologies if I have missed other arguments against this approach.
Besides simplicity, its biggest advantage is that it gives back-ends full freedom to satisfy the requirements of their users, as niche or sophisticated as they could be.
To flesh it out a little bit, it could look like this, with two new back-end methods.
build_wheel_for_develop(wheel_directory, config_settings=None, metadata_directory=None)
The only requirement for that method is that the built (partial) wheel must include .dist-info
metadata. For the rest it may be empty, or contain any other content typically found in a wheel.
develop(target_directory, config_settings=None)
This method is responsible for additionally making sure, if needed, that the project is importable when, at runtime, target_directory
is in sys.path
.
This method must return the list of files (or symlinks, it does not matter) created in target_directory
and any of its sub-directories.
This method is optional, since a way to handle simple cases is for the back-end to add a .pth
file in the wheel generated by build_wheel_for_develop
.
The front-end would work like this for editable installs:
- Same behavior as a normal install except that it calls
build_wheel_for_develop
in place ofbuild_wheel
. The partial wheel is installed normally, including dependencies, console scripts creation, etc. - When the partial wheel is installed, the front-end calls
develop(target_directory)
withtarget_directory
depending on front-end options (–user, --target, --root). - The front-end appends the files returned by
develop
toRECORD
(with hash, except for symlinks which are recorded without hash). - The front-end records a PEP 610
direct_url.json
with the project directory asurl
anddir_info['editable'] = True
.
In terms of POC, I personally glimpse quite clearly how that would work in pip
and flit
, and I assume implementing that in setuptools
is not too hard (at least to achieve the equivalent of the current setup.py develop
).
Hard hat on, send feedback please