@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.
But like, TBH, even with just the local version stuff, the “doing things unknowingly” is extremely unlikely and I’m happy with that too.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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”.
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.
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.
May be this help but I still lost in reading all of this - they all lengthy and sound too complicated to have short explain
I described what I think is going on above:
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).
I was wondering the same. It would either:
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 610direct_url.json (simply containing {"editable": true}); it would (still) be the installer/orchestrator job to provide the additional fields url/vcs_info/archive_info@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.