Um, so if a backend supplies a wheel containing symlinks on a platform that doesn’t support them (just so we don’t continually make Windows the scapegoat, how about Linux installing to a FAT32 partition on an external drive? 
) - what should the frontend do? Fail the install? What would it tell the user? How would the user address the issue (assuming that they were happily using editable mode in a pre-PEP517 environment, and really don’t care about symlinks vs .pth)?
I would say it’s the back-end responsibility to fail or downgrade gracefully if it runs on a platform that does not support symlinks. Or to cover your FAT32 example, the front-end could pass an option to build_wheel_for_develop to tell the back-end if symlinks are supported or not in the target environment.
Sounds fair. See my other post on standardising the runtime support for editable installs. We need to agree that symlinks are an option so that we can agree that the frontend tells the backend if they are supported, so the backend can have the information it needs to downgrade gracefully.
… or we just say to heck with it, pip supports editable installs using .pth files just like we use now, and if the backend wants capabilities we don’t support then tough 
2 Likes