uv pip install failes for wheel URLs with placeholder

[mil-ad]

I was following the vllm nightly installation guide where they have this one-liner for installing their nightly wheels:

pip install https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl

Their documentation specifically says:

The version string in the wheel file name (1.0.0.dev) is just a placeholder to have a unified URL for the wheels. The actual versions of wheels are contained in the wheel metadata.

when using uv pip install I get:

error: Failed to install: vllm-1.0.0.dev0-cp38-abi3-manylinux1_x86_64.whl (vllm==1.0.0.dev0 (from https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl))
  Caused by: Wheel version does not match filename: 0.6.3.dev155+gf3a507f1.d20241010 != 1.0.0.dev0

but doing vanilla pip install works.

[charliermarsh]

My initial reaction is that it seems correct to fail here (I'm somewhat surprised this recommend this), and pip's lack of enforcement seems more like a bug than a feature.

[mil-ad]

I think I agree. I hadn't seen this pattern before.

[konstin]

It violates the Python packaging specs (the binary distribution spec requires the version to be in the wheel name), so i consider this a bug in their packaging system - Thanks for filing the upstream bug!

[gaardhus]

I just ran into the same issue with the same package. Are you guys thinking of adding a flag to circumvent this, or should I try to push for them to change their practice? FWIW I don't think it's a bug as in unintended on their part, but an "easy" way to let people install the latest nightly version without having to update the url accordingly?

[konstin]

but an "easy" way to let people install the latest nightly version without having to update the url accordingly?

This can be done by using a --find-links index (basically a flat html page with links to source distributions and wheels) or a full index with the nightly package. The wheel version of a filename needs to be fixed, otherwise resolvers such as uv process the file properly in the dependencies graph.

[gaardhus]

Roger that, will turn to the vllm repo then

[ywang96]

A few of us from the vLLM project are addressing this issue so that you can use uv to install nightly wheels - See vllm-project/vllm#11404

[connorblack]

Running into this with the huggingface.co/docs/bitsandbytes package as well.

The wheel it fails with:

• https://github.com/bitsandbytes-foundation/bitsandbytes/releases/download/continuous-release_multi-backend-refactor/bitsandbytes-0.45.0.dev0-py3-none-manylinux_2_24_x86_64.whl

[charliermarsh]

I believe this has been (or is being) fixed with vLLM specifically, but in general I think this is the correct behavior for uv.

For bits-and-bytes, it seems like they should be including the local tag in the wheel filename... Though we can make it optional.

[dsantiago]

Running into this with the huggingface.co/docs/bitsandbytes package as well.

The wheel it fails with:

• https://github.com/bitsandbytes-foundation/bitsandbytes/releases/download/continuous-release_multi-backend-refactor/bitsandbytes-0.45.0.dev0-py3-none-manylinux_2_24_x86_64.whl

+1 Same problem here with bitsandbytes