Fix pip cache remove pattern matching.
#13094
Conversation
Previously, glob patterns were not properly accounted for, which could lead to `pip cache remove wheel-0.45.1-py3-none-any.whl` failing, for example, when exactly that file was shown to exist in the cache via `pip cache list`. Additionally, non-glob patterns previously only literally matched wheel project names; now they match the normalized name. For example, `pip cache remove pyfftw` will now remove a cached `pyFFTW-0.15.0-cp313-cp313-linux_x86_64.whl` wheel since the `pyfftw` pattern matches the normalized project name. Fixes pypa#13086
| glob_pattern_char in pattern for glob_pattern_char in ("[", "*", "?") | ||
| ) | ||
| if not uses_glob_patterns: | ||
| project_name, sep, rest = pattern.partition("-") |
There was a problem hiding this comment.
N.B. I documented punting on deciphering glob patterns with respect to name normalization. Someone braver than I might try that later. I assume forward progress here is better than no progress though.
I did not, however, call the shot on version normalization. Again, I was cowardly, but that problem still remains. If a wheel in the cache is foo-1.0-py3-none-any.whl, then, in my opinion, pip cache remove foo-1.0.0 should remove it, but does not today.
| # PEP 427: https://www.python.org/dev/peps/pep-0427/ | ||
| pattern = pattern + ("*.whl" if "-" in pattern else "-*.whl") | ||
|
|
||
| return filesystem.find_files(wheel_dir, pattern) | ||
| # And: https://packaging.python.org/specifications/binary-distribution-format/ |
There was a problem hiding this comment.
For Pip / PyPA knowledgeable reviewers - what the heck is up with this by the way? I've always found it off-putting since the PEP banners have started appearing on some of the PyPA PEPs re-directing to these new standards pages. The fact that some PEPs get a new page and some don't and what process the ones with the new page go through to get updated is all mysterious feeling.
There was a problem hiding this comment.
This change makes the implementation more in-line with my intentions back in #6391.
The glob check in particular looks way more robust now. 🙂
|
This is another place in pip's codebase where I wish we were relying on packaging instead of hand rolled normalization techniques. I want to suggest using So maybe this is a better solution for now, at least until packaging offers a more complete filename API. |
I strongly agree with @notatallshaw. I'd like to not roll our custom logic for matching against cache entries if possible, but if packaging's utilties aren't ready for that yet, then an interim solution is fine (as long as it can easily be replaced by packaging w/o too much fuss). I know that this PR is waiting for my review. It is next on my list to review, sorry for the wait! |
|
Heads up, CI is going to fail due to a new setuptools release from ~6 hours ago. Setuptools now normalizes the filenames of the wheels it emits. This isn't your problem, just don't bother retrying CI. |
Previously, glob patterns were not properly accounted for, which could
lead to
pip cache remove wheel-0.45.1-py3-none-any.whlfailing, forexample, when exactly that file was shown to exist in the cache via
pip cache list.Additionally, non-glob patterns previously only literally matched wheel
project names; now they match the normalized name. For example,
pip cache remove pyfftwwill now remove a cachedpyFFTW-0.15.0-cp313-cp313-linux_x86_64.whlwheel since thepyfftwpattern matches the normalized project name.
Fixes #13086