Generator is the name and optionally the version of the software that produced the archive.
Tools such as auditwheel or delocate alter and rewrite wheels by packing external dependencies inside of them. Excluding these tools from the wheel metadata would cause any problems or regressions from these tools to be harder to track down.
As a maintainer of delocate I’ve made the unwitting decision to add a 2nd Generator field, to annotate which version of Delocate modified that wheel, but this broke other third party tools such as wheel-inspect which expects only a single instance of Generator. The documentation is ambiguous and doesn’t clearly state that either of these approaches are wrong. My interpretation was that tools writing or rewriting a wheel are supposed to be in the wheel metadata as a Generator, and to omit or replace a Generator field would obfuscate the wheels origins. I didn’t want a wheel that was potentially broken by delocate to say it was only touched by setuptools, etc.
It does not seem like the original specification accounted for there to be more than one tool used to create a wheel in the first place. This is combined with a file spec which allows for and documents examples of duplicate keys which causes the ambiguity.
I was hoping to hear an authoritative answer to these questions:
Is the Generator field one only, or one or more?
How should the names/versions of additional tools used to generate a wheel be tracked?
I don’t think it’s clear in the spec (unfortunately, a common problem with the wheel spec) but the implication of the wording seems to me to be that only one generator was expected.
I don’t personally have any issue with the idea of making the field multi-use, but it would need feedback from wheel-inspect and any other tools that you’re aware of which broke, to clarify how such a change would affect them. But for me, the logic that it makes tracking down the cause of problems easier is pretty compelling.
Procedurally, the process for such a change requires a discussion here, leading to a decision as to whether it can be handled as a text-only change, or it requires a PEP. I’m inclined to view this as small enough to not require a PEP - but that heavily depends on the views of the affected tools.
I’m the author of wheel-inspect, and I believe supporting multi-use Generator fields would mostly be a one-line change, possibly accompanied by a major version bump due to the change in the output schema.
I should’ve brought this up with you directly a long time ago. It was a wheel-inspect user who pointed out this issue in the delocate repo, so it’s unlikely you would’ve seen it.
Might be worth noting that adding new Generator fields naturally creates a history. Where the first Generator is the tool which originally created the wheel and subsequent Generator’s are the tools which modified it in order. So keeping only the first Generator would let wheel-inspect work with the latest delocate wheels without affecting the output from normal.
I think wheel-inspect was the only tool with known issues for about a year. I had previously posted this question to the wrong forum (pypa/packaging.python.org GitHub Issues) where it received no attention until I was recently told to move it here.
So this might be a change to PEP 427 and PEP 491. Either to allow for multiple Generator fields or to expressly forbid having more than one.
No, this would be a change to the packaging.python.org page about the spec, not the PEPs which are historical documents to create or (non trivially) update the specs.
Right. I was confused about whether or not this counted as affecting “software interoperability” according to the linked process. It becomes much simpler when I assume it doesn’t.
It does, but interoperability changes are allowed to be handled as textual edits if there is community consensus that it’s ok to do so.
If a change being considered this way has the potential to affect software interoperability, then it must be escalated to the Packaging category of the Python.org Discourse for discussion, where it will be either approved as a text-only change, or else directed to the PEP process for specification updates.