Coming up with the implementation detail of achieving an editable installation is what I consider here the lifting. Who has to implement the mechanism that makes an import resolve to a source tree file. And with PEP-660 this falls onto every build backend individually (who may share that code via the editables package - but the same way frontends can share this logic in a package).
This is not true the way I understand thigns. Currently, we have no standard solutions. pip/setuptools operates with pth files and flit operates with symlinks (note here flit is both frontend and backend). PEP-660 would make flits solution out of standard and only the pip/setuptools way is sanctioned.
In a world where this PEP is accepted some frontends can use the pth file solution of pip/setuptools, some frontends can choose the symlink path; or any other alternative mechanism they wish to do so. Does some mechanism over benefits over others? Sure. But the frontends may document this, and then the end-user can choose one which they’re comfortable with. Or some frontends might decide to implement multiple mechanisms and let the user choose.
There’s an example of this within the PEP. Can you detail what do you think is a limitation that stops you from doing this?
Not necessarily. Some solutions might be platform-dependent, and some frontends might be happy to target just some platforms. Frontends that intend to be cross-platform compatible are not required to adopt these solutions. Especially in corporate world being platform-dependent is not a big issue.
Yes, but should the backend be in control of choosing between symlink/pth or the frontend. With PEP-660 the backend is in charge, and cannot support a symlink solution. With this PEP the frontend is in charge and can support both mechanism, and provide an API for the end user to choose.
Depends. The user might be willing to settle for the pth path because its platform does not support it and accept that the exclusion list will not work. The idea here is to allow the frontend to have multiple strategies, each with its own trade-offs and put the choice in the end-users end, because the frontend is the one directly communicating the the end-user.
Considering the backend is the one generating the files to install there’s no way to disallow it to take over. However, the backend has that choice in his hands. Can decide to pass files through transparently and not have to deal with the complications of import hooks or not, and then implement some import hook based solution.
There’s no way to mandate this. E.g. when you’re merging files during the build you’re clearly not having a file that you can just point to. The paths for the simple cases should point to the on-disk source file, but in general, you can’t mandate that requirement, because often there’s no source to link in.