Not really. pip already contains logic to install wheels. The only change needed is to read the distribution information not from a wheel file but instead straight from a dist-info. In practice, this results in only needing to skip the extract/read from the zip phase of the wheel. All other mechanisms can and should be reused.
In my mind, this is an implementation detail for the frontend and there’s no need to mandate it. Frontends are free to zip up the dist info returned by the backend to create a wheel and feed that to their wheel installer. Or just alter their wheel installation logic to take in not just a wheel file and look into a dist-info folder in that, but also a take the dist-info folder directly. They’ll need to alter their wheel installation either way though to support the scheme mapping so adding support for reading from dist-info folder is not that hard.
You’re free to create a competing PEP that does so, however, this PEP does not and will not take that angle. I want to offer the option for frontends to do more than just purelib/platlib. Basically anything that’s possible to install via a wheel, should be allowed to be doable via a virtual wheel, as detailed in:
We refer to this set of information as the virtual wheel. This virtual wheel
should contain all information a wheel contains, however it's not zipped and
its installation will not be done by copying the files.
This is so that we don’t have to create another PEP in 6 months to support data files, and then include files and scripts and so on.
I don’t think we as a community are in an agreement as what’s typical. Is it typical to support python files, or inline C-extension, or data files? Is it typical to auto-discover new files for the project? This PEP aims to not make that decision, and leave it up to the frontend to decide how much it wants to support; and how it achieves that. Granted this might mean that different frontends on different platforms might support a different subset of editables. Or that frontends might offer different variations of typical editable installation, and let the user choose based on their needs and cons they’re willing to live with. However, I think that’s fine. Editable is only meant to be used by the developers of the project, so their target user group is smaller. And I’ve added into the PEP that a frontend that cannot satisfy the requirement of the backend should raise an error to the user and explain why not. At which point the user might alter its project code or choose a different frontend.