In PEP 815, we propose to deprecate RECORD.jws and RECORD.p7s. These in-archive signatures have never seen any widespread support or usage, notably they aren’t supported in pip nor uv. Users looking to verify wheel provenance should instead use index hosted attestations, which are more modern, out-of-archive and supported by tooling.
The PEP is written under the assumption that these files aren’t used. If you are a user of them or know a tool that uses them, please share!
Usage data
To add some data to the unused claim, we can use the GitHub search:
We also checked Tom Forbes’ PyPI Data with the following query:
select
project_name,
max(toYear (uploaded_on)) as year,
countIf(endsWith(path, '.dist-info/RECORD.jws') OR endsWith(path, '.dist-info/RECORD.p7s')) as total_files
from pypi
group by project_name with rollup
having total_files > 0 or project_name is null
order by year desc, total_files desc;
This yields the following table, where year means “most recent year there has been a release with one of the files”: signature_files.csv · GitHub
Closing words
We usually take great care around deprecations, but unless there is usage of these signature files we have missed, I’d like to keep this as simple as possible for a deprecation with no affected tools or users.
Thanks for writing this @konstin! I’m registering my strong support for this PEP: I think the downsides are marginal (= effectively zero), and that formally deprecating these two signature accommodations will make explicit the informal deprecation that’s already in place.
I don’t argue against the PEP, but I’m interested what the intended outcome of this is? Are there people pressuring tools to add support for these because they aren’t officially deprecated? Do we want tools to detect and scream about them? Do we want PyPI to block uploads with these files?[1]
Without an intended outcome, it seems like there’s nothing gained or lost? So… why?
For the record, my answers are: “nothing”, “ignore them”, “no”, “hell no!”. ↩︎
My assumption is that @konstin is trying to be a good steward by writing fully spec-compliant tooling, but has (IMO, correctly) deduced that this one is not worth the effort for them or anyone else, and rather than just ignoring it, has gone a step above to attempt to bring our standards up to date with reality.
The outcome here is that there is one less PEP that new (and old) tools need to contend with, I think that alone is worth doing.
I’ve done a lot of spec reading over the past year or so and when you find that tools aren’t following the spec it can be hard to deduce if it was missed on purpose, forgotten about, misunderstood, or the wording doesn’t correctly convey the intentions
Having a clearly deprecated part of the spec would save time trying to understand if the ecosystem supports it or not, and if not why.
Yeah, this was the source of the pre-PEP thread: we observed that these signatures were basically nonexistent in practice and that standard tooling had long stopped supporting them (or more accurately, even noticing them), so updating the standards to reflect the “ground truth” is IMO a useful part of ensuring that consumers of the standards have an accurate view of what is and isn’t actually used by the ecosystem
Thanks @konstin for writing this into a PEP (and @emmatyping for sponsoring it)! AFAICT, the only actual change this needs is a PR to packaging.python.org as well, which would be good to file too.
Ideally, this would have been a PR against packaging.python.org that removes this outdated part from the living spec, likely with an announcement for due diligence, but substantially it’s maintenance ensuring that our documentations and our implementations align. As the process requires a full PEP for this change, I wrote a PEP.
