Conversation
Signed-off-by: William Woodruff <william@yossarian.net>
|
CCing some other folks who I think might be interested: @konstin @miketheman |
| 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 | ||
| The tarball MUST use the modern POSIX.1-2001 pax tar format, which specifies |
There was a problem hiding this comment.
I suspect the lowercasing of this "must" wasn't meant to de-emphasize its normativity, so I'm uppercasing it.
| The use of pax-style vendor extensions (such as ``SCHILY.xattr`` or ``LIBARCHIVE.xattr``) | ||
| is NOT RECOMMENDED for interoperability reasons. |
There was a problem hiding this comment.
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?
| Source distributions MUST NOT use non-pax features, even if those features are | ||
| structurally compatible with the pax standard. Installers and other consumers MAY | ||
| reject source distributions that are not strictly pax-conforming. |
There was a problem hiding this comment.
Maybe come right out with it?
"sdists must not include any pax Vendor Extensions"
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Oh, I read this in the wrong section. Yeah, I'll strengthen this.
2 participants
I'm opening this as a direct living spec PR, since it's arguably just a clarification of the existing requirement, not a new one 🙂. However, if there's disagreement about that, I'm happy to take this to DPO for discussion first.
My rationale: the sdist spec already says that the tarball must be a POSIX.1-2001 pax archive. This implies a bunch of things that people may not realize, but are already fully covered by that requirement. For example, GNU-style tar files are not pax-conforming (they use a different magic and have special extended value encoding rules), and the
Stypeflag is GNU-specific.There's a passable argument to be made that
GNU.sparse.*is pax-conforming, since they're pax-style records. However:GNU.sparse.*are illegal to represent in pax, since they use duplicated record names;GNU.sparse.*in general changes the framing logic, making it hard to correctly model the parse of a sparse member with a standard pax-conforming parser.Finally, I think the most controversial part of this is adding a
NOT RECOMMENDEDfor other pax-style (but not standard) vendor records. These are technically allowed in pax, just not defined by the standard themselves. However, they're also subject to a bunch of interoperability problems. For example,SCHILY.xattris sometimes encoded as raw binary, which is not pax-conforming and causes problems for standard parsers.(And more generally, Python source distributions have no business encoding xattrs or anything like that, from what I can tell 🙂)
📚 Documentation preview 📚: https://python-packaging-user-guide--2108.org.readthedocs.build/en/2108/