In my view the most important benefit of PEP 660 compared to virtual wheels is that it allows for easier experimentation and innovation.
It seems quite clear that the community has a wide range of theoretical and practical expectations about editable installs. The reality is that the only one there is wide experience with is path insertion via .pth (i.e. what setup.py develop does). editables is a very promising approach, yet it has been mentioned it does not cover all use cases.
With PEP 660, several approaches are possible without any change to the specification nor to frontends. For example these only require backend variations:
- insert a directory in python path (à la .pth)
- expose specific files (à la
editables) - allow for a different source layout in the project and installed code
All these would require additional wording in a virtual wheel specification, plus specific frontend support, in addition to backend support.
So, in my opinion the additional specification and implementation complexity of virtual wheels is real, and would certainly cause more delay.
While I do understand and appreciate the argument that the choice of “editable style” should be left to the frontend/developer, I think it is not worth the additional complexity, especially knowing that this choice can still be passed to a PEP 660 backend via config settings [1] or another environmental mechanism.
I plan to add wording like this in the rejected ideas section of PEP 660 that refers to virtual wheels. I hope it captures the essence of the discussion.
If there are other ideas that were mentioned elsewhere that people feel should be mentioned in PEP 660, just let me know.
[1] config settings have not been implemented because they lack concrete use cases and no-one has really asked for them so far