maturin generates non-pax source distributions

[ww-oai]

Bug Description

Hey maturin folks,

This is a kind of weird one: PEP 625 defines the source distribution format, and says that compliant source distributions must be pax-style tars:

An sdist must be a gzipped tar archive in pax format, that is able to be extracted by the standard library tarfile module with the open flag 'r:gz'.

Ref: https://peps.python.org/pep-0625/#specification

(To make things confusing, the living version of the sdist spec mis-transposes "must" into "should," but the spec says "must.")

On the other hand, maturin generates GNU-style tar headers:

maturin/src/module_writer/sdist_writer.rs

Line 44 in ba72f74

let mut header = tar::Header::new_gnu();

On top of that, the tar crate itself produces "chimera" archives: even if the user explicitly calls new_ustar instead, inserting an entry with an over-long name will cause the decoder to insert a GNU-style longname rather than a proper pax local extension. This is documented here:

https://docs.rs/tar/latest/tar/struct.Builder.html#method.append_data

And is also noted here: composefs/tar-rs#318

The end result of this is that maturin both explicitly and implicitly produces sdists that are technically in violation of PEP 625. I say technically because in practice all installers/consumers are generally permissive of GNU and other non-pax tar variants. Still, I think conformance with the PEP is a good thing to aspire for 🙂

In terms of fixing this, I think there are a few options:

1. maturin could call new_ustar instead, and manually perform the pax extension fixup by bypassing Builder::append_data. This is relatively minimal but requires maturin to duplicate some of the path validation logic that's currently internal to the tar crate.
2. maturin could switch to astral-tokio-tar, which I'm planning on refactoring to principally support pax encoding (while still supporting GNU and v7 decoding). The downside to this is that astral-tokio-tar is that it's async, so maturin would need to wrap it a bit.

CC @zanieb @konstin

Your maturin version (maturin --version)

1.13.3 (but also present on main)

Your Python version (python -V)

N/A

Your pip version (pip -V)

N/A

What bindings you're using

None

Does cargo build work?

• Yes, it works

If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /)?

• Yes

Steps to Reproduce

This is a standards conformance bug, not a behavioral bug per se. You can reproduce this by inspecting any sdist produced by maturin (for example, those of uv or cryptography) and observing that they use GNU-style headers rather than USTAR headers (of which pax is a superset).