After reviewing the two PEPs on editable installs, and the (extensive) discussion on the subject, I have made my decision.
PEP 660 is hereby accepted, and consequently, PEP 662 is rejected.
Thanks to the authors of both PEPs for the amount of work they put into developing the PEPs, handling the discussions and writing proof of concept code, and to everyone else involved in the discussions for useful feedback and comments.
As usual, I’ll provide a summary of the reasoning behind my decision below. Feel free to ignore it if you’re not interested
First of all, I would like to put the proposals into context. If we had been designing an “editable installation” mechanism from scratch, then IMO the discussion would have been very different, and to be honest I suspect that ultimately we’d have ended up rejecting the whole idea. However, that’s not the situation we’re in - we have editable installations, implemented by setuptools since the very early days, and in use by many, many projects. So the goal here is not to design a feature, but to work out how to standardise and extend that feature (both to support other backends, and if possible to address problems with the existing implementation).
My approval of PEP 660 is based very much on the fact that it achieves the goal of standardising the existing functionality, while adding some support for improvement. It has its limitations (in particular, it doesn’t handle symlink-based approaches, and it concentrates mainly on sys.path
entries) but those are acknowledged in the PEP and are in line with the existing .pth
based setup.py develop
mechanism, for better or worse.
The arguments made for more flexibility in letting the user control how the editable mechanism is chosen were strong, to the extent that they were probably the main concern I had with deciding in favour of PEP 660. However, PEP 662 in my view failed to address the major point raised by all reviewers, that the interface between the frontend and the backend was unclear, and badly specified. The point was made repeatedly, but ultimately the PEP’s only response was “that’s for the tools to decide”, which I don’t believe addressed the questions raised. I could have sent PEP 662 back for revision before making a decision, but the PEP author clearly stated that not specifying was a deliberate choice, so it didn’t seem like that was going to make any significant difference. As a result, I did not consider PEP 662 to have adequately defined the mechanism it was proposing, and I therefore did not feel that I could reasonably approve it.