[Bug]: 1.0.0.dev placeholder doesn't work with uv pip install

[mil-ad]

Your current environment

na

Model Input Dumps

No response

🐛 Describe the bug

The recommended way for pip installing latest wheels (i.e. pip install https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl) works with vanilla pip but does not work with uv pip. I raised an issue in uv but I don't think this is a uv bug. Would be great to explore more robust options for this.

Before submitting a new issue...

• Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

[cjackal]

I think the installation guide must be updated somehow like

1. first download the wheel from s3 w/ e.g. curl
2. rename the wheel file with the "correct" version inscribed in the wheel METADATA (it requires some unzip yoga, I suppose)
3. (uv) pip install the renamed wheel file

Current (mis)behavior of pip successfully install wrongly-named wheel file is kind of antipattern - not only uv but many repository managers (e.g. sonartype Nexus) that provide pypi mirror support may also check the wheel filename version with wheel metadata version, which would be main blocker to maintain a private mirror for vllm wheels

[dtrifiro]

The problem is that the wheel files should not be renamed, perhaps we need to rethink the approach introduced in #8919

[tovacinni]

Why shouldn't the wheel file be renamed?

Here's a bash script that gets a whl file compatible with uv:

#!/bin/bash

# Check if URL is provided
if [ $# -eq 0 ]; then
    echo "Usage: $0 <wheel_url>"
    exit 1
fi

URL=$1
WHEEL_FILE=$(basename "$URL")
ORIGINAL_DIR=$(pwd)
TMP_DIR=$(mktemp -d)
cd "$TMP_DIR" || exit

echo "Downloading wheel file..."
wget -q "$URL" || { echo "Failed to download wheel"; exit 1; }

# Create temporary directory for wheel contents
EXTRACT_DIR="${TMP_DIR}/wheel_contents"
mkdir -p "$EXTRACT_DIR"

# Unzip the wheel file
unzip -q "$WHEEL_FILE" -d "$EXTRACT_DIR" || { echo "Failed to unzip wheel"; exit 1; }

# Find the METADATA file
METADATA_FILE=$(find "$EXTRACT_DIR" -name "METADATA")
if [ -z "$METADATA_FILE" ]; then
    echo "METADATA file not found"
    cd "$ORIGINAL_DIR" || exit
    exit 1
fi

# Extract version from METADATA
VERSION=$(grep "^Version:" "$METADATA_FILE" | cut -d " " -f 2)
if [ -z "$VERSION" ]; then
    echo "Version not found in METADATA"
    cd "$ORIGINAL_DIR" || exit
    exit 1
fi

# Extract components from original filename
# Assuming format: name-version-pythontag-abitag-platformtag.whl
BASE_NAME=$(echo "$WHEEL_FILE" | cut -d "-" -f 1)
REMAINDER=$(echo "$WHEEL_FILE" | cut -d "-" -f 3-)

# Construct new filename
NEW_NAME="${BASE_NAME}-${VERSION}-${REMAINDER}"

# Move file to original directory with new name
mv "$TMP_DIR/$WHEEL_FILE" "$ORIGINAL_DIR/$NEW_NAME"

# Return to original directory
cd "$ORIGINAL_DIR" || exit

echo "Original version: $VERSION"
echo "Normalized version: $NORMALIZED_VERSION"
echo "Renamed wheel file to: $NEW_NAME"

# Cleanup
rm -rf "$TMP_DIR"

[youkaichao]

I admit this exploits pip's misbehavior.

What I want to keep, is the ability to have a single command to install the latest wheel, without changing anything.

I think ultimately we need to go to the pip index approach outlined in #9831 (comment)

[dtrifiro]

While this specific bug still exists, it's now possible to install the latest nightly version like so:

uv pip install --extra-index-url "https://wheels.vllm.ai/nightly/" vllm

[youkaichao]

close as we have a solution for uv now, see the comment above from @dtrifiro , and the blog post https://blog.vllm.ai/2025/01/10/dev-experience.html