I have revised my opinion on this matter since I posted that. My view is now:
- There have been sufficient use cases presented that I think symlink support is worth having. A cross-platform use case that hasn’t been mentioned here so far is implementing editable installs via symlinks in the created wheel.
- I remain -1 on using the “native” support for symlinks in the zip format. It seems not to be standardised, and support isn’t universal. Also, I expect that we would want better control of what happens when symlinks aren’t available than just leaving that to a library to deal with.
- We would need some rules around what symlinks are allowed - for example, do we want to allow links to files not bundled in the wheel? That’s necessary for editable wheels, but do we want to somehow limit it to only that use case?
- As I mentioned above, we need to decide what behaviour we want when an installer tries to install a wheel containing symlinks on a platform/filesystem/session without symlink support.
Because of all of these points, I think we should treat symlink support as needing a PEP, and hence a new version of the wheel spec. I will note that the spec doesn’t distinguish between “minor” and “major” specification version changes, so it technically doesn’t matter whether this is Wheel 1.1 or Wheel 2.0.
In particular, I do not think that symlink support qualifies as simply a “clarification” of the wheel spec.
Is anyone interested in writing a PEP / championing this change?