PEP 778: Supporting Symlinks in Wheels

[ethanhs]

Posting here to reserve the PEP numbers and posting the text of PEP 778 to share on discuss.

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Rationale
  • Specification
  • Backwards Compatibility
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

---

📚 Documentation preview 📚: https://pep-previews--3786.org.readthedocs.build/pep-0778/

[hugovk]

Hi Ethan! We normally assign the next available PEP numbers (for example, 747), what's the justification for jumping up to 777?

@warsaw Please can you confirm you're sponsoring the second PEP here ("Supporting Symlinks in Wheels")?

And we need a sponsor for the first one ("Reinventing the Wheel (Wheel 2.0)" - excellent title btw!). @warsaw Will you sponsor this one as well?

And for next time, we normally don't open a PEP discussion thread (https://discuss.python.org/t/pep-778-supporting-symlinks-in-wheels/53824) until after the draft PEP has been merged into the repo - it means a first pass review and fixes can be made, but more importantly, means we have a stable PR for people to review. We've had situations where people were still looking at the old PR preview even after merge and subsequent PR updates.

[ethanhs]

Hey Hugo! Sorry! I selected 777 because I expect a series of related PEPs (wheel 2.0) and I wanted to have their numbers grouped together (like 482, 483, 484), if someone puts a new PEP up between now and when I get to writing the other PEPs, it would break the grouping. I posted to discuss to get feedback on 778 while I work on 777.

Sorry for not following the process I'll try to follow it more closely in future.

[warsaw]

Please can you confirm you're sponsoring the second PEP here ("Supporting Symlinks in Wheels")?

Confirmed!

[warsaw]

@warsaw Will you sponsor this one as well?

Just to be explicit, yes I'll sponsor this one as well.

[hugovk]

Please could you copy the "New PEP" template into the PR message and check them off?

https://github.com/python/peps/blob/main/.github/PULL_REQUEST_TEMPLATE/Add%20a%20new%20PEP.md

For example, please also add Barry to the CODEOWNERS file for these.

[hugovk]

Suggested change

	cases and caveats (especially platform suppport) of symlinks in wheels. Otherwise it should be
	cases and caveats (especially platform support) of symlinks in wheels. Otherwise it should be

[ethanhs]

Was there a change you wanted to suggest here? I don't see any diff.

[hugovk]

I'm not sure what happened there! Edited to remove the third P in "suppport".

[geofft]

EDIT: this was indeed raised in the Discourse thread already.

For symlinks - have you looked at the approach @njsmith took for pybi and the rationale for it? https://github.com/njsmith/posy/blob/main/pybi/README.md#symlinks

They are stored both as actual symlinks in the zip file with one of the common extensions for representing them, and as metadata in the RECORD file. This means that if you're just using a naive zip tool (e.g. unzip xyz.whl) on a system that supports symlinks, you'll get the right content, but if you're on a platform that doesn't directly support symlinks, it can ignore the symlink entries in the zip file and look at the RECORD file alone.

In general I think it would be good to unify wheel 2.0 with pybi as far as possible / make it so that the pybi format doesn't need to exist and it's just wheel 2.0.

(BTW - are you all still at sprints?)

(Also should I be commenting here or on the Discourse thread?)

[hugovk]

(Also should I be commenting here or on the Discourse thread?)

Discourse for more general discussion like this, thanks.

[ethanhs]

Ah, this won't build cleanly until 777 is merged in. I'll make sure to update the MR after that so it builds correctly. Also, I've added the checklist template to the original message.