In what way is it restrictive ? In terms of capabilities I have yet to see something that one can do and not the other.
What prevents a new version of setuptools that implements PEP 660 to generate the built extension in another directory and expose that one ?
You can define a C extension just fine with ensconsâ SConstruct, no setup.py required. Maybe pymsbuild does it too. Even the distutils 2 attempt from a decade ago put extensions in setup.cfg. setup.py does no magic it just knows a few compiler flags.
C extensions should work fine with .pth or import hooks same as .py
The truest Python old-timers still set PYTHONPATH but the package would not show up in pip list which sometimes matters.
backend specific, no plan to standardize until we have more experience
How is it different for editables than a regular pep 517 build ?
Again Iâm not sure how it is different than regular PEP 517.
I guess weâre having a disgreement on symlink functionality. You say one can do via inserting a startup code into the interpreter that performs the symlink operation. I donât think this is a smart approach we should publicize. In essence the backend is creating files into the target interpreter the frontend is not aware. The frontend will not be able to uninstall these because it doesnât know they exist. Or the backend needs to generate pre-emptively entries into the RECORDS that are not there, but can be there. Not sure if the RECORDS file within wheels supports this, or if frontend would not choke on it either at install or uninstall time.
In theory, it can. However, feels like thereâs an easier solution by defining an interface where the frontend can explicitly create the symlink, and not mandate the need of a meta folder to achieve this functionality.
I donât see any mention on this topic on PEP 517 either. So Iâd like to ask for clarifications on the question here.
The existing hooks in PEP 517 do not pass in any target interpreter specific information in PEP 517. PEP 660 for some reason does pass in the scheme argument that seems to tie it to a specific interpreter and nothing else. So while you can take a universal wheel and reuse it across multiple interpreters, the defined interface seems to discourage this. The PEP should be clear if it does not plan to offer similar guarantees PEP 517 does.
I donât think we should take the stance that reorganize your project or its configuration to make it editable friendly. I believe desiging a system that can solve the problem without this would be prefered.
The scheme argument is still subject to discussion and Iâm more and more convinced we should remove it from PEP 660.
I know this is only part of whats going on but once this PEP is completed our plan to kill setuptools is complete.
You donât have to switch to enscons. But once you can do âdevelopâ mode without setup.py then setuptools has no preferred place in packaging.
Iâm not sure how this is relevant at all here. Iâm by no means a setuptools maintainers. And both the virtual wheels and the PEP-660 gets you there independent of what alternative backend you want to go with.
Just avoid saying setup.py is required for extensions or that setuptools must implement all packaging standards or those standards cannot exist.
Why donât we return to the other thread to discuss how virtual wheels implement âexpose a whole pathâ versus âexpose a packageâ versus âexpose a list of .py filesâ
Iâve been mildly interested in adding symlink support to wheel. What if we added a permissions column to RECORD. If it contains a lowercase l, interpret the content of that file as a symlink. Optionally set the standard zip file symlink attribute.
Then this PEP could request symlinks.
Yes that would open up additional possibilities for PEP 660 but that should treated separately, and not as a prerequisite for PEP 660 adoption, because it is useful without symlinks.
Iâm drilling down on the objectionsâŠ
Regarding headers and data files, PEP 660 puts them explicitly out of scope in the Terminology and goals section, by saying we focus on making python files editable. If supporting editable headers and data files become a key criteria for adopting an editable PEP, then itâs symlinks or 
, I suppose ?
Regarding scripts, well, Iâm personally fine to say they canât be editable and recommend project authors to migrate to console scripts if they want that. Editable scripts does not sound like a strong differentiator, especially if the only known way to implement that is symlinks.
You run your script in the checkout no problem and it can import your Python.
I disagree. Sure itâs useful but Iâd say not complete without it. In a world where PEP-660 gets accepted and symlink PEP rejected, weâd be worse off than a competing proposal that would add support for symlinks. So if we go down this lane Iâd like the two PEPs to be accepted/rejected together.
In mind editable installs are about Python packages, not python files. So in this sense I guess the two PEPs currently have different goals. Similar to how PEP 517 covers packaging for editable packages, and not pure Python projects this pep should also cover packages not files.
I donât think symlinks would work here, but proxy scripts generated would, so I see no reason why not go down that path.
Itâs not about setup.py file per se, but yes backends should be able to handle their existing use cases in the new standardized way, so weâre not progressing some while regressing in other parts.
Where did the symlink requirement come from? It seems odd to block on support for platform-dependent functionality.
Maybe, as a Windows user, I am seeing things differently?
Yes, I hope that we can decide that this implemented PEP is fine as is and without symlinks, making it easier to provide a feature that many people like. The âstrictest possible simulation of an install without actually copying the filesâ idea is different, could we call it âpreflightâ mode?
The problem would be adding new scripts, but that could be solved by adding a communication back channel to trigger the frontend to generate them.
Windows 10 from the last few years does support symlinks, you should try to use it helps a lot efficiency/performance in virtualenv for example 
I think based on discussion above we can conclude that we canât agree and weâll have to let the packaging BDFL or the steering council pick a solution. Many people do want editable installations, but both PEP provide this functionality so thereâs no this reasoning canât be used by either option.
We do still have to work out exactly what the other proposal would do before it can be claimed to be equivalent.