# Offer a "dumb" PEP 517 develop hook

**URL:** <https://discuss.python.org/t/offer-a-dumb-pep-517-develop-hook/3937>\
**Category:** Packaging\
**Created:** [April 18, 2020, 4:37pm UTC](https://discuss.python.org/t/offer-a-dumb-pep-517-develop-hook/3937 "2020-04-18T16:37:50Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![sbidoul](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sbidoul/32/244_2.png) [@sbidoul](https://discuss.python.org/u/sbidoul)\
**Post date:** [May 4, 2020, 9:01pm UTC](https://discuss.python.org/t/offer-a-dumb-pep-517-develop-hook/3937/14 "2020-05-04T21:01:43Z")

</div>

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 🙂 👷‍♂️

---

_[View the full topic](https://discuss.python.org/t/offer-a-dumb-pep-517-develop-hook/3937)._