Hijacking this thread after the discussion of one implementation for PEP 660 (wheel-based editable installs) where symbolic-links are used (first mention).
In this case, the wheel is guaranteed to be intended for local (and therefore platform-specific) use, so as long as project build back-ends don’t try to put symlinks into a wheel when they’re unsupported/disabled on Windows, everything should be fine?
Some resources I’ve discovered:
- symlink-extraction BPO: Issue 27318: Add support for symlinks to zipfile - Python tracker (summary:
if stat.S_ISLNK(member.external_attr >> 16)) - PIP issue with some discussion (closed, and refers to this thread): Symlink (and other) handling of archives · Issue #5919 · pypa/pip · GitHub
- SO answer on storing symlinks: zip - archiving symlinks with python zipfile - Stack Overflow (summary:
zipInfo.external_attr |= 0xA0000000) - GitHub PR for a better interfacing with symlinks inside Zip files: https://github.com/python/cpython/pull/15401
For this to be useful for editable installation, I’d imaging for all versions of Python which don’t support symlinks in zips, both wheel installers and build back-ends (that support editable wheels?) will need to subclass (or patch) zipfile.Zipfile to support symlinks. This sounds like interoperability concern, where back-ends can only start using symlinks when all (supported?) wheel-installers support symlink extraction. Back-ends can’t provide symlink support to wheel-installers as they’re in a separate environment.