Thanks, I wasn’t aware there’s an open PR.
There’s an open PR from a new(?) contributor for this.
Yeah hello 
I’m definitely new[1] in the sense of I haven’t contributed much to the core packaging landscape. I’m technically a PyPA member as I’m a committer on the pypa/bandersnatch project but for all intents and purposes I may as well be a “first-time contributor”. For background I’ve been quietly following Python packaging as it developed and I wanted to see if I could make a PEP 660 implementation in setuptools (both to help out and to see if my packaging knowledge was actually decent haha). I managed to get a functional implementation of the .pth editable install functionality (note it’s 100% not tested with compiled packages) and since I was aware of how slowly PEP implementation has been I thought it’d be a good idea to submit it as a PR. I probably should’ve made it clearer that it was a bit hacky since now I feel like people are expecting me to get the PR landed 
The setuptools maintainers don’t want to implement their PEP 660 support as a drop in replacement via a pth file, but instead want to implement it via a different mechanism to “clean up some of the major failings of the current editable install mode”.
I honestly have no ground to stand on here. I chose the .pth approach because it was simpler and “just works” for implicit namespace packages (the editables library does not provide any benefits for implicit namespace packages over the .pth approach). To be honest I have no idea what a “strict” mode implementation would look like or work.
I’m still open to continuing work on the PR (I did look in the dist-info vs egg-info discrepancy yesterday) but be warned I will probably ask many questions. Apologies for misguiding y’all expectations. I’m also happy to have someone else picking up the PR (or straight replacing it if it sucks too much).
the only way you would have heard of me is either through the PyPA Discord server or psf/black which I co-maintain ↩︎
1 Like
I agree with you here. It’s ultimately up to the setuptools maintainers what implementation mechanism they want to use, though, and if they are unwilling to use the current .pth approach, that’s their choice. If as a result they block their implementation of PEP 660 while they work out what mechanism they want to use, then so be it, I guess.
TBH I really did not expect this question to ruin everyone’s holidays… so, yeah, sorry.
I posted this following a private inquiry from the packaging project manager about any roadblocks to PEP 660 implementation. I was not aware of any, so I figured it was a good idea to do the last step now.
Since backends are happily implementing it, and users seem satisfied with how it works in practice, and we have had exactly zero question about spec clarification, and one setuptools maintainers was asking to incorporate Daniel’s prototype in setuptools, and there are no known technical issues with incorporating it in setuptools, and we were satisfying PEP 1 criteria to move to Final status… I was kind of assuming this was a no brainer.
The only thing I was expecting push back on was about incorporation of PEP 660 at packaging.python.org, which is blocked on having PEP 517 itself there.
2 Likes