# PEP 660 and setuptools **URL:** \ **Category:** Packaging\ **Created:** [April 5, 2022, 6:46pm UTC](https://discuss.python.org/t/pep-660-and-setuptools/14855 "2022-04-05T18:46:22Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\ **Post date:** [April 13, 2022, 11:35am UTC](https://discuss.python.org/t/pep-660-and-setuptools/14855/2 "2022-04-13T11:35:18Z")
This is a pretty good summary about the lack of consensus: [Standardising editable mode installs (runtime layout - not hooks!)](https://discuss.python.org/t/standardising-editable-mode-installs-runtime-layout-not-hooks/4098). Some developers consider the behaviour as a _“serious long-standing bug”_ while others are very happy with the trade-off\[1\] and would experience frustration with a _stricter_ approach, since it can potentially disturb their workflow. My opinion is that all depends on the target audience and intended usage: 1. A user that wants to develop incrementally a package and play/tinker with it in the CLI is probably interested in a _“loose/lax”_ implementation that automatically picks up new files (this is required to support important workflows like splitting existing files in smaller pieces or general refactoring). 2. A user that wants to test\[2\] the package (either the final version or an intermediate version after a big chunk of work) is probably interested in a “strict” implementation that emulates as close as possible the installed behaviour of the final distribution artifact. Because of the reasons in (2.c), I would argue that the main benefits of having a “strict” editable install **by default** are (unfortunately) undermined. To actively take advantage of an “strict” editable install, the users also need to be aware of `PYTHONPATH` “poisoning” and all the tricks to prevent it. Therefore, since these users already have to actively take extra measures to perform a “strict” test methodology, I don’t think it would be problematic to require an “opt in” for “strict” editable installs. On the other hand, as previously mentioned in (1), if we make the “strict” editable install the default, users would be probably be frustrated by setuptools not fulfilling the existing expectations. (In summary it would be a “breaking change” that would likely upset a lot of users). It is also important to notice that the audience in (1) has pretty good reasons for wanting `editable` installs to be “lax/loose”, therefore I think that classifying this trade-off behaviour simply as a long standing bug is an oversimplification. # Proposal In order to address the comments and concerns presented in the preceding discussions about the theme, my proposal is that `setuptools` should implement both the _“strict”_ and the _“lax/loose”_ approaches for editable installs. However, when not specified otherwise by the users, the installation should be perfomed in the _“lax/loose”_ mode. Initially, `setuptools` can expose an environment variable (e.g. `SETUPTOOLS_EDITABLE=strict`) to allow users to opt-into the _“strict”_ mode, just as a transitional measure. But after some time, it would be nice if the existing installers provide an interface for the users to change the editable mode to _“strict”_ without having to set environment variable\[6\]. Merely illustrative example of how that could be done: ```bash pip install -e --strict . # OR pip install -e --mode=strict . # OR pip install --editable=strict . # etc… ``` The installer/build-frontend would then call the PEP 660 hooks passing an appropriate/pre-agreed key/value pair in `config_settings`. Merely illustrative example: ```bash config_settings = {“editable_mode”: “strict”} # OR config_settings = {“strict”: True} # etc … ``` * * * 1. In order to automatically pick up new files the implementation also looses the ability of recognizing when a file would not be present in the final distribution. 2. _tests_ here mean not only automated tests but also checks performed manually/in a ad-hoc way by the user. 3. The word _expectation_ is used here in the same meaning as in _“managing expectations”_. Users may _wish_ editable installs would work in a strict way, but currently when they do `pip install -e .` they don’t _expect_ it to be strict. 4. There are popular blog posts, conference talks, videos, etc that date as far as 2015 (or even further). For example: [Tox tricks and patterns | ionel's codelog](https://blog.ionelmc.ro/2015/04/14/tox-tricks-and-patterns/) 5. In this text I use the _ **unwary user** _ expression to refer to users that (a) are not aware that they should be testing the packages _as if it was installed_ to prevent accidental errors, _OR_ that (b) are not actively interested in taking this extra measures. 6. It seems that there is already some positive support in the `pip` team about improving the UI for this use case: [Implement PEP 660 hooks in setuptools/build\_meta.py by ichard26 · Pull Request #2872 · pypa/setuptools · GitHub](https://github.com/pypa/setuptools/pull/2872#issuecomment-1002146271), [Implement PEP 660 hooks in setuptools/build\_meta.py by ichard26 · Pull Request #2872 · pypa/setuptools · GitHub](https://github.com/pypa/setuptools/pull/2872#issuecomment-1002190830). --- _[View the full topic](https://discuss.python.org/t/pep-660-and-setuptools/14855)._