Suggest a pip upgrade on UnsupportedWheel if the upgrade check is disabled
geofft opened this issue · 3 comments
What's the problem this feature will solve?
There's a proposal (PEP 777) for a wheel 2.0 format. As discussed starting around https://discuss.python.org/t/pep-778-supporting-symlinks-in-wheels/53824/45 , people don't always upgrade their version of pip, and it would be good to specifically encourage them to do that if pip hits a wheel version it doesn't support.
If the built-in version check is enabled, the existing output happens to be in the right order to make it clear how to resolve your problem:
$ bin/pip install --index-url http://localhost:8000 --trusted-host localhost attrs
Looking in indexes: http://localhost:8000
Collecting attrs
Downloading http://localhost:8000/attrs/attrs-23.2.0-py3-none-any.whl (63 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 63.2/63.2 kB 126.7 MB/s eta 0:00:00
ERROR: attrs has an invalid wheel, attrs's Wheel-Version (2.0) is not compatible with this version of pip
[notice] A new release of pip is available: 23.3.2 -> 24.0
[notice] To update, run: python -m pip install --upgrade pip
But if the check is disabled, then you don't really get any suggestion about how to solve the problem. Also, if the version check has happened in the last week, and a new pip version + new wheel format has happened since then, pip does not re-check.
Describe the solution you'd like
If we hit UnsupportedWheel, and the version upgrade check is enabled, ignore the time cache and always do a re-check.
And if the version upgrade check is suppressed for some other reason (either because of the option or because pip is externally installed), print a generic warning message like "Upgrading to a newer version of pip may solve this issue" without specifically telling you to use pip to do the upgrade.
Alternative Solutions
N/A
Additional context
I am happy to send in a PR, but I started doing it and found it's a little bit hairy so I want to make sure people think this is a good idea before I continue.
Code of Conduct
- I agree to follow the PSF Code of Conduct.
I think it's premature to do something like this. The Wheel 2.0 PEP should describe the transition plan (not just for pip, but for all installers) and pip will then follow that plan once the PEP has been accepted.
That seems fair to me, but I think as soon as there's consensus in favor of any of the changes that would necessitate wheel 2.0, we should start writing and implementing that transition plan, because the exact people who would be helped by this kind of change are the people who upgrade pip rarely / run old versions. So getting an imperfect (but correct, of course) message sooner is valuable.
And yes, this is broader than just pip.
I'm not sure what you mean by "consensus in favor of any of the changes that would necessitate wheel 2.0" here. You seem to be suggesting that Wheel 2.0 will be introduced as a concept independently of the functionality that it introduces (the split between PEPs 777 and 778 suggests this as well). That seems unlikely to happen - although as PEP 777 hasn't yet been published, I can't really comment properly at this stage.
As I said, let's not rush to make changes in pip while the whole concept of "Wheel 2.0" is still unclear.
I'll follow up (briefly) on the PEP 778 thread on Discourse, because I think we're getting very ahead of ourselves by depending on a PEP that's not even been written yet...