Thank you for the reminder and the summary of above discussions. I think my intent from the above subthread (since my first post) was to understand if there were other constraints still being worked out that I should be aware of as an implementor.
There are general questions of caching and data architecture for python resolvers that are almost completely irrelevant to the wheel format, which is a format for local and network distributions of python dists. I was trying to understand that distinction above—thanks for grounding me.
Ambiguity in Wheel Versioning
I’m trying now to work out the mechanics of how to publish a wheel that uses PEP 777 to mark its Wheel-Version, and there are a few points that remain unclear to me:
- What format does the
Wheel-Versionstring conform to? Both in the sense of generating a valid one for new experiments as well for correctly parsing one.- The current standard (Binary distribution format - Python Packaging User Guide) says:
Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater.
or:
Wheel-Versionis the version number of the Wheel specification.
If it can be any valid string conforming to the current version (Version specifiers - Python Packaging User Guide) specification, great! But the specific identification of “minor” and “major” version (unchanged from the wheel 1.0 PEP) implies a much more restrictive X.Y format.
But also now that I think about it, I don’t think I’m actually allowed to just make up a version string, right? Because the capital W Wheel specification refers to the result of a standards process?
Cyclic Dependency
I am probably missing something here, but I don’t see how to get out of the chicken-and-egg problem if I can’t test against or even build an experimental wheel format until it’s already an accepted PEP. I could certainly add my own ad-hoc marker to my experimental wheels, but I would also then need to recognize that marker in my resolver/installer too, and get everyone else who wants to try the format to recognize that ad-hoc marker.
The constraints defined in Limitations on Future Wheel Revisions and that Paul kindly reiterated just above seem to give free rein to experimentation, but I don’t understand how to close the loop and actually resolve or install a funky new wheel format without adding another separate field besides Wheel-Version alone, and that makes me nervous. Maybe experimental wheel formats would just be a separate proposal? But that seems to defeat the purpose of “Re-inventing” the wheel!
In pre-PEP: User-Agent schema for HTTP requests against remote package indices, I proposed turning pip/25.2 <json> into pip/25.2 (PEP NNN) <json>, because the name/version convention for User-Agent is already established, but we needed a generic way to signal conformance to the proposed standard that was separate from client name and version. We have even less flexibility than that here, because the Wheel-Version is not something we can change on a whim.
But let’s say I just bite the bullet and add my own ad-hoc field to identify my experiments–PyPI only speaks Python standards, so it wouldn’t understand any upload that’s not backwards-compatible with its declared Wheel-Version (maybe that’s fine?). And like my telemetry PEP proposal, it seems to benefit PyPI to know if users provide input that’s supposed to be experimental.
Have I missed an obvious answer that would allow deploying my funky new wheel format e.g. to PyPI as opposed to my own index? Right now, it seems like the way to do that is:
- Ensure it’s backwards-compatible with a declared wheel version,
- Add a separate field (into
.dist-info/WHEEL? but what if I want to resolve against it too?), - Use a modified resolver which recognizes the ad-hoc marker from (2).
I think I’m missing something here! Sorry!