pip incorrectly interprets version symlinked whl file name

[bpkroth]

Description

When using tools like setuptools-scm for automatic git versioning we get semi random versions. For instance:

mypackage-0.6.1.dev18+g238ae95057-py3-none-any.whl

To workaround this in CI pipelines we have previously created symlinks like the following:

mypackage-latest-py3-none-any.whl -> mypackage-0.6.1.dev18+g238ae95057-py3-none-any.whl

and then test inspecting, installing, etc. the mypackage-latest-py3-none-any.whl file.

However, recently this started failing with messages like the following:

conda run pip install "mypackage/dist/tmp/mypackage-latest-py3-none-any.whl[full-tests]"

ERROR: Invalid requirement: 'mypackage==latest': Expected end or semicolon (after name and no valid version specifier)
    mypackage==latest

However, inside the whl file the appropriate version is listed in the METADATA.

This doesn't happen if we do the following instead:

conda run pip install "`readlink -f mypackage/dist/tmp/mypackage-latest-py3-none-any.whl`[full-tests]"

In effect, we ask it to install the full path to the target file instead (i.e., mypackage-0.6.1.dev18+g238ae95057-py3-none-any.whl).

This seems like a recent regression in that it is using the version from the filename instead of from the whl METADATA.

Version info:

# pip --version
pip 24.2 from /opt/conda/lib/python3.12/site-packages/pip (python 3.12)

Expected behavior

pip should read version info from the whl file, not the filename argument, or at least the absolute file path.

pip version

24.2

Python version

3.12

OS

Linux

How to Reproduce

1. cd mypackage
2. python -m build
3. ln -s dist/mypackage-*-py3-none-any.whl dist/mypackage-latest-none-any.whl
4. pip install dist/mypackage-latest-none-any.whl

Output

ERROR: Invalid requirement: 'mypackage==latest': Expected end or semicolon (after name and no valid version specifier)
    mypackage==latest

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[notatallshaw]

However, recently this started failing with messages like the following:

Can you confirm for what version of pip this was working for you? I can reproduce the error, but testing back to pip 20.0.3 I get the same error.

[bpkroth]

Sorry for the delay. I will try and test it out, but it only showed up for us in the last week or so, I think with a change in the version of pip inside conda-forge.

[notatallshaw]

There's no rush, but I think it must be understood if this changed then when it changed so it can be determined if it was intentional or not.

The thing is, your proposed solution would cause the same error for anyone doing the opposite, e.g. {valid-wheel-name.whl} linked to "blob.whl".

Perhaps no one is doing this, but perhaps it’s intentional that that workflow works.