# PEP 660: Editable installs for PEP-517 style build backends **URL:** \ **Category:** Packaging\ **Created:** [May 2, 2021, 10:38am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510 "2021-05-02T10:38:07Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [May 6, 2021, 10:54am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/42 "2021-05-06T10:54:53Z")
@sbidoul I think it’s fine to not require changing the version number, since it’ll be duplicated anyway. The concern is that a build backend might not do that and users would be capable of mixing things unknowingly. By enforcing a tag, that possibility is eliminated. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [May 6, 2021, 10:58am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/43 "2021-05-06T10:58:14Z")
But like, TBH, even with just the local version stuff, the “doing things unknowingly” is extremely unlikely and I’m happy with that too. ---
**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 6, 2021, 10:58am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/44 "2021-05-06T10:58:27Z")
In the PEP I tried to explain why the local version identifier is useful. _Build-backends are encouraged to append a distinguishable PEP 440 local version identifier, such as `+editable`, so as to make editable installs easier to identify by users inspecting installed distributions. Since public index servers reject wheels containing local version identifiers, this approach has the interesting property of preventing accidental publishing of editable wheels. The version must otherwise be identical to what would have been produced by `prepare_metadata_for_build_wheel` so as to ensure correct dependency resolution._ ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [May 6, 2021, 11:02am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/45 "2021-05-06T11:02:45Z")
Ah. My bad. Then, I feel like we don’t have to change anything then. It’s already extremely unlikely and given that the wheels will have the word “editable” in them if the build backend follows the recommendation, that’s even more unlikely. I’m not sure there’s any valid reason to add complexity in wheel installers to disallow these wheels from being mixed. ---
**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\ **Post date:** [May 6, 2021, 1:14pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/46 "2021-05-06T13:14:39Z")
The issue I see with the `editable` version marker is that no tool can reliably be sure that the wheel is meant to be editable. ---
**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 6, 2021, 1:31pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/47 "2021-05-06T13:31:07Z")
If we make it a MUST for the backend to include the `editable` string in the local version identifier, there will be a way. Not without change to existing installers, of course, but there are not that many in the wild. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [May 6, 2021, 1:34pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/48 "2021-05-06T13:34:02Z")
Do you think it would be a nuisance if editable wheels replaced the Python tag with the word ‘editable’ so that the filename would be `package-1.0-editable-none-any.whl`, or the abi or platform tags `packagename-1.0-py3-editable-any.whl` or `packagename-1.0-py3-none-editable.whl`? The installer would have to ignore tags or replace a string in the list of supported tags while installing this wheel. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [May 6, 2021, 1:37pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/49 "2021-05-06T13:37:34Z")
I think that would be more than “a nuisance”. Existing installers, and libraries like packaging, all ignore wheels that don’t match the current system’s compatibility tags (that’s basic behaviour from the existing wheel PEP, as you’re aware). All of those would need to change somehow. Personally, I don’t think that’s something pip would agree to. Conversely, the local version identifier is something that pip can support right now. ---
**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\ **Post date:** [May 6, 2021, 1:46pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/50 "2021-05-06T13:46:27Z")
This only matters if you are looking to support `pip install`-ing editable wheels right now. The use case for that is pretty small and should only really affect tooling that wants to use `pip` internally to install editable wheels, but that tooling hasn’t been written yet so it could very well require a minimum version of pip, or use a library like `installer`. I only think this would be more than a nuisance for the use case of _users_ `pip install`-ing editable wheels. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [May 6, 2021, 2:13pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/51 "2021-05-06T14:13:23Z")
It would matter if pip went through the standard tag checking process while installing the editable wheel. It could modify the list of supported tags while installing the editable wheel. Today, enscons generates wheels like `package-1.0-ed.py3-none-any.whl` which is already allowed. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [May 6, 2021, 2:15pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/52 "2021-05-06T14:15:29Z")
> [@pradyunsg](#): > > I’m not sure there’s any valid reason to add complexity in wheel installers to disallow these wheels from being mixed. Unless someone can come up with a reason to add complexity here beyond users like `i-like-chaos` being able to “mix” these wheels, I suggest we move on from this topic. As far as I can tell, all of us agree that this isn’t a blocking concern for the PEP. ---
**Author:** ![uranusjr](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/uranusjr/32/103_2.png) [@uranusjr](https://discuss.python.org/u/uranusjr)\ **Post date:** [May 6, 2021, 5:36pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/53 "2021-05-06T17:36:20Z")
Even with the `-editable` naming scheme, the orchastrator still must pass the correct wheel to the correct installer function, which still feels suboptimal to me. Would it be possible to change the responsibility to create `direct_url.json` from the orchastrator to the build backend, and put it directly inside the editable wheel’s dist-info directory, and require the installer (or orchastrator) to validate it before installing? I don’t think there are rules prohibiting additional files in a wheel’s dist-info directory, and this would allow tools more reliably identify an editable wheel and know how to do with it without additional information (i.e. where the editable wheel points to). ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [May 6, 2021, 9:12pm UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/54 "2021-05-06T21:12:11Z")
> [@FFY00](#): > > no tool can reliably be sure that the wheel is meant to be editable. This looks like an important misconception. The _wheel_ is not editable, it doesn’t even contain the project. It’s literally just “whatever files should be copied into `site-packages`/equivalent for Python to find the original project”. Maybe that’s code, maybe it’s configuration, maybe it’s some core functionality that hasn’t been invented yet. It doesn’t matter - the only thing to be done with the wheel file is extraction. If we didn’t define this as “follows the wheel spec”, we’d be defining it in terms of sysconfig (the one we’re in the middle of changing) and types of data files (the ones that are being discussed in other threads), and expecting build backends to copy files around themselves (a.k.a. what setuptools does today). From the POV of the tools, it doesn’t even need to be a wheel with a _valid name_. They’re not going to search for it - it’ll be provided by full path. There’s no logic for these files to be platform-specific or version-specific because they’re already way more specific than that. Copying them anywhere else would just be a mistake, much like copying a symlink (without its target) to another machine is a mistake. And just like people will occasionally get symlinks wrong and discover it when they try to use it, people will discover that “that weird temporary wheel I found and copied wasn’t the right one, and maybe I should have generated it properly”. Some errors we don’t have to work too hard to protect users from. This is one of them. ---
**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\ **Post date:** [May 7, 2021, 1:12am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/55 "2021-05-07T01:12:36Z")
> [@steve.dower](#): > > The _wheel_ is not editable That’s why I said “meant to be”. My point is that “editable wheels” have a very specific set of requirements, which do not get properly represented in the wheel metadata. > [@steve.dower](#): > > Some errors we don’t have to work too hard to protect users from. This is one of them. I agree, however, I don’t think adding some sort of marker/tag that a wheel is meant to be editable, so that it conveys these requirements, much like we do for platform or abi, is “working too hard”. ---
**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\ **Post date:** [May 7, 2021, 1:14am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/56 "2021-05-07T01:14:49Z")
Can someone please briefly explain what `orchestrator install -e .` would call internally in terms of build backend, build frontend, and installer? I don’t understand the point at which the `-e` flag information seemingly gets lost. ---
**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\ **Post date:** [May 7, 2021, 1:24am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/57 "2021-05-07T01:24:53Z")
But anyway, it is clear the consensus is that such a marker is not really needed, though generally welcome, if I understand correctly, which I accept. So, please move along the PEP, I really don’t want to block progress and I feel I have already wasted way too much time voicing my concerns. If you could make `+editable` mandatory, that would be great, but please just move the PEP along 😊 I can still discuss my option if anyone wants, but I wanted to make it clear that any discussion from my part should not affect progress. ---
**Author:** ![nhatkhai](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nhatkhai/32/3950_2.png) [@nhatkhai](https://discuss.python.org/u/nhatkhai)\ **Post date:** [May 7, 2021, 2:37am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/58 "2021-05-07T02:37:48Z")
May be this help but I still lost in reading all of this - they all lengthy and sound too complicated to have short explain > [@Standardising editable mode installs (runtime layout - not hooks!)](https://discuss.python.org/t/standardising-editable-mode-installs-runtime-layout-not-hooks/4098): > > Once again, the discussion on editable mode seems to have started going in circles. We now have at least the following threads on the subject: [Offer a “dumb” PEP 517 develop hook](https://discuss.python.org/t/offer-a-dumb-pep-517-develop-hook/3937)[Pip 19.1 and installing in editable mode with pyproject.toml](https://discuss.python.org/t/pip-19-1-and-installing-in-editable-mode-with-pyproject-toml/1553)[Third try on editable installs](https://discuss.python.org/t/third-try-on-editable-installs/3986) I’ve reached the point where I’m convinced that the problem is not about designing hooks to communicate between backends and frontends, but rather the more fundamental question of what “develop mode” or “editable mode” actuall… ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [May 7, 2021, 7:34am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/59 "2021-05-07T07:34:12Z")
> [@ofek](#): > > Can someone please briefly explain what `orchestrator install -e .` would call internally in terms of build backend, build frontend, and installer? I described what I think is going on above: > [@pf\_moore](#): > > I’m assuming that the _only_ workflow that involves editable wheels is as follows: > > - Installer gets told “install this directory in editable mode” ( `pip install -e .` ) > - Installer calls `build_wheel_for_editable` > - Installer unpacks and installs the returned wheel, and adds the `direct_url.json` file containing the directory named in the original request. I’m also not clear where people are worrying the `-e` flag gets lost. I don’t quite know what people mean by the term “orchestrator” so I’m using “installer” here. I suspect the first two steps above are “Orchestrator does X” and the last is “Orchestrator asks installer to unpack and…”. (My perspective is pip, which is probably both an “orchestrator” and an “installer” in this context). ---
**Author:** ![xafer](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/xafer/32/248_2.png) [@xafer](https://discuss.python.org/u/xafer)\ **Post date:** [May 7, 2021, 9:09am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/60 "2021-05-07T09:09:55Z")
> [@uranusjr](#): > > Would it be possible to change the responsibility to create `direct_url.json` from the orchastrator to the build backend, and put it directly inside the editable wheel’s dist-info directory, and require the installer (or orchastrator) to validate it before installing? I don’t think there are rules prohibiting additional files in a wheel’s dist-info directory, and this would allow tools more reliably identify an editable wheel and know how to do with it without additional information (i.e. where the editable wheel points to). I was wondering the same. It would either: - require the `build_wheel_for_editable` hook to accept another argument `direct_url` containing the `url`/`vcs_info`/`archive_info` information needed by the build backend to produce a complete `direct_url.json` file compliant with PEP 610 - require the produced wheel to simply contain a partial `direct_url.json` (simply containing `{"editable": true}`); it would (still) be the installer/orchestrator job to provide the additional fields `url`/`vcs_info`/`archive_info` ---
**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 7, 2021, 9:27am UTC](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510/61 "2021-05-07T09:27:46Z")
@xafer note that PEP 610 says that the `editable` flag in `direct_url.json` is only available in `dir_info`. It is not available for archives or VCS URLs. This is because an editable install only makes sense when the project is available locally. The `pip install -e {vcs-url}` mechanism is just a shortcut for vcs checkout + `pip install -e {local-dir}`. Since the backend knows the project location, no additional parameter would be needed for that. But even that is not sufficient for allowing an installer to correctly install a wheel that comes out of `build_wheel_for_editable` without additional context. Indeed, the `scheme` is passed to `build_wheel_for_editable` and the installer must use the same scheme when installing the wheel. So that would be an additional information to add in the wheel. On top of that I have a bad feeling with asking the backend to put direct\_url.json in the wheel, as PEP 610 was designed with installers in mind. [Previous page](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510.md?page=2) [Next page](https://discuss.python.org/t/pep-660-editable-installs-for-pep-517-style-build-backends/8510.md?page=4)