Offer a "dumb" PEP 517 develop hook

Packaging
14

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 of build_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) with target_directory depending on front-end options (–user, --target, --root).
  • The front-end appends the files returned by develop to RECORD (with hash, except for symlinks which are recorded without hash).
  • The front-end records a PEP 610 direct_url.json with the project directory as url and dir_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 :slight_smile: :construction_worker_man: