Skip to content

sdist format: qualify pax compatibility #2108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
woodruffw wants to merge 2 commits into
base: main
Choose a base branch
from
Open

sdist format: qualify pax compatibility #2108

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7705a46
sdist format: qualify pax compatibility
woodruffw Aug 18, 2026
89cf209
Strengthen
woodruffw Aug 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions source/specifications/source-distribution-format.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,10 +74,19 @@ at their respective paths relative to the root directory of the sdist
No other content of a sdist is required or defined. Build systems can store
whatever information they need in the sdist to build the project.

The tarball must use the modern POSIX.1-2001 pax tar format, which specifies
UTF-8 based file names. In particular, source distribution files must be readable
The tarball MUST use the modern POSIX.1-2001 pax tar format, which specifies

@woodruffw woodruffw Aug 18, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect the lowercasing of this "must" wasn't meant to de-emphasize its normativity, so I'm uppercasing it.

UTF-8 based file names. In particular, source distribution files MUST be readable
using the standard library tarfile module with the open flag 'r:gz'.

Source distributions MUST NOT use non-pax features, even if those features are
structurally compatible with the pax standard. Installers and other consumers SHOULD
reject source distributions that are not strictly pax-conforming.
Comment on lines +81 to +83

@miketheman miketheman Aug 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe come right out with it?
"sdists must not include any pax Vendor Extensions"

@woodruffw woodruffw Aug 18, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only reason was that these are technically pax conforming in a more meaningful sense. So I didn't want to jump to changing the plain meaning of the spec itself, but if nobody objects...

@woodruffw woodruffw Aug 18, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I read this in the wrong section. Yeah, I'll strengthen this.


Examples of non-pax features include GNU-style or legacy ("V7")-style tar members
and sparse member encodings (e.g. ``GNU.sparse`` extensions or ``S`` typeflag members).

The use of pax-style vendor extensions (such as ``SCHILY.xattr`` or ``LIBARCHIVE.xattr``)
is NOT RECOMMENDED for interoperability reasons.
Comment on lines +88 to +89

@miketheman miketheman Aug 18, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hear you on the trying to soften the blow, but if one goal of the Python packaging ecosystem is to remain compatible and interoperable, why not draw the line stronger, and save some future selves from having to deal with this?


.. _sdist-archive-features:

Expand Down
Loading