Searching for terms “symlink”, “zstd”, “wheel-version” on this forum, I skimmed the following discussions for relevant objections to (or support for) installers stopping on unexpected wheel version:
- 2019 May Improving wheel compression by nesting data as a second .zip
- Wheel version not mentioned.
- 2019 Jul Symbolic links in wheels
- Wheel version 1.1 and 2.0 were discussed, but I spotted no objections.
- 2020 Apr-Sep Making the wheel format more flexible (for better compression/speed)
- dstufft: “we’d want … that pip can support failing to install a wheel that is made with a newer version with a meaningful error … The other options would be a weird, hard to debug error for older versions of clients OR making a
.whl2or something that pip wouldn’t see as a valid old style wheel.” - pf_moore: “original wheel spec was designed with a wheel version embedded precisely so that new versions could be introduced cleanly, I’d be very uncomfortable with a new wheel version that throws away that versioning scheme before it’s even been of benefit for a single release bump. … if we don’t follow the wheel versioning standard then the new format should probably be given a new name and be treated as a replacement for wheels, not a new version of the wheel format”
- No objections I think.
- dstufft: “we’d want … that pip can support failing to install a wheel that is made with a newer version with a meaningful error … The other options would be a weird, hard to debug error for older versions of clients OR making a
- 2020 Jul - 2022 Sep PEP 625: File name of a Source Distribution
- sdist 1.1 and 2.0 were discussed. I spotted no discussion of wheel version bump nor objections.
- 2021 May-Aug PEP 658: Static Distribution Metadata in the Simple Repository API
- Wheel version 2.0 is mentioned but I spotted no objections.
- 2021 May-Dec PEP 660: Editable installs for PEP-517 style build backends
- Wheel version 1.1 is barely mentioned. No objections I think.
- 2022 Dec Require packing wheels without files in the root directory
- pradyunsg: “to better understand how a new version of wheel would roll out, and not try an incompatible version bump and hope that we get the rollout right on the first attempt based on educated guesses”
- 2022 Dec-2023 Jan Speculative: Wheel 2.0 and migration strategies
- No objections? There seemed to be consensus concluding:
- pradyunsg: “migration to a new wheel version is a tractable problem” (via “different rollout schedules”)
- 2023 May Proposal - expanding optional dependencies to support opt-out of recommended/default installables
- The version handling is mentioned.
- uranusjr: "
pip install foowill install different things depending on what version of pip the user has … this issue would likely cause confusion".
- 2024 May-Jul PEP778 Supporting symlinks in wheels
- PEP 777 was mentioned as an outlook, but I don’t see objections except:
- pf_moore: “one of the big problems here is that wheel format versioning needs a rethink - as the “what will pip do with version 2.0 wheels” subthread established, a major version bump is very disruptive”.
- I think that subthread was extracted into its own thread:
- 2024 May Ways to update pip and when updating is a good idea
- The extracted subthread.
- geofft, kknechtel: pro auto-updating pip or showing stronger hints to update
- steve.dower: pro pinning pip on CI
- 2024 May-Jun How to reinvent the wheel
- Precursor of this topic, so the question is discussed (recently).
- pf_moore: “any package that depends on the one with a 2.0 wheel will also fail to install”
- geofft: “encode the feature dependencies as normal dependencies, instead of creating a new metadata field for it and requiring new installers to be able to parse that.”; later proposes .whl2
- rgommers: " upload both
.whland.whl2for a long time, to avoid a fallback to building from sdist. That price is way too high - I’d prefer to see an error whenpipis too old"
The most convincing reason that the errors could be disruptive seems to me pf_moore’s observation in that last thread. But overall rollout schedules, error messages and suggestions to upgrade pip seemed rather accepted. Maybe I missed discussions in other places (github, older mailing lists) or failed to note an important objection?