Fixing uv add Errors with Python ML Packages

Running uv add transformers and getting a cryptic error is one of the first frustrations when setting up an AI development environment. uv has become the fast, modern alternative to pip, but machine learning packages have complex dependency graphs that expose a few specific rough edges.

Here's a rundown of the most common failure modes and how to fix them.

Error 1: Python Version Mismatch

error: No solution found when resolving dependencies:
  × No versions of `torch>=2.0.0` found for Python 3.13

torch, transformers, and most major ML libraries don't yet support the latest Python versions. Python 3.13 is the common culprit right now.

Fix: Pin the Python version

# Start a new project with Python 3.11
uv init --python 3.11 myproject
cd myproject
 
# Or pin an existing project
uv python pin 3.11

Python 3.10–3.11 is the sweet spot for ML package compatibility right now. This single change resolves the majority of "no solution found" errors.

Error 2: Dependency Conflicts

error: Because `package-a` requires `numpy<1.24` and `transformers` requires `numpy>=1.24`,
       we can't install both.

Two packages require mutually incompatible versions of a shared dependency.

Fix: Install heavier packages first, or pin constraints explicitly

# Install torch first — it anchors the dependency resolution
uv add torch
uv add transformers
uv add accelerate
 
# Or pin the conflicting package explicitly
uv add "numpy>=1.24,<2.0"
uv add transformers

There's also --no-deps to force installation while ignoring dependencies, but treat that as a last resort — it can produce a broken environment that's hard to debug.

Error 3: CUDA/CPU PyTorch Conflict

error: torch 2.1.0+cu118 and torch 2.1.0+cpu cannot coexist

A CUDA build and a CPU build of PyTorch are conflicting.

Fix: Specify the index URL explicitly

# Install CUDA 11.8 build
uv add torch --extra-index-url https://download.pytorch.org/whl/cu118
 
# Or configure it in pyproject.toml

In pyproject.toml:

[tool.uv.sources]
torch = { index = "pytorch-cu118" }
 
[[tool.uv.index]]
name = "pytorch-cu118"
url = "https://download.pytorch.org/whl/cu118"
explicit = true

With this in place, uv add torch will consistently pull the CUDA build. Adjust cu118 to cu121 or similar based on your CUDA version.

Error 4: Build Failures for Compiled Packages

error: Failed to build `pyarrow==14.0.0`
  × Failed to run `cargo build`...

Some packages like pyarrow and sentencepiece require Rust or C++ compilation, which can fail if the build toolchain isn't available.

Fix: Prefer pre-built wheels

# Use binary wheels only (no compilation)
uv add pyarrow --prefer-binary
 
# Or pin a version with reliable wheel availability
uv add "pyarrow==13.0.0"

Pre-built wheels avoid the compilation step entirely and install much faster.

One-Command ML Environment Setup

Putting the above together, here's a reliable sequence for setting up an Antigravity + ML development environment:

# 1. Create project with Python 3.11
uv init antigravity-project --python 3.11
cd antigravity-project
 
# 2. Add PyTorch first (choose CPU or CUDA)
# CPU build (easier to start):
uv add torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cpu
 
# CUDA build (for GPU environments — adjust cu118 to match your CUDA version):
# uv add torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu118
 
# 3. Add Transformers and related packages
uv add transformers accelerate datasets
 
# 4. Dev tools
uv add --dev jupyter ipykernel
 
# 5. Verify
uv run python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

When to Use pip Instead

uv is excellent for new projects and controlled environments, but some scenarios still favor pip:

uv is better for: new projects, strict dependency management, migrating from requirements.txt to pyproject.toml

pip is easier for: existing requirements.txt-based projects, inline !pip install in Jupyter notebooks, quickly trying commands copied from official docs

A pragmatic split: use uv for new projects, stick with pip for existing ones until you're comfortable with the migration.

Nuclear Option: Reset the Environment

If nothing else works, delete and recreate the virtual environment from scratch:

# Remove and recreate the virtual environment
rm -rf .venv
uv sync
 
# Or reset the lock file too
rm -rf .venv uv.lock
uv add torch transformers

uv.lock is a snapshot of the resolved dependency graph. If a problematic version combination got locked in, deleting it forces a fresh resolution. This tends to work when you've been adding and removing packages in a way that left the lockfile in an inconsistent state.

Don't Confuse uv add with uv pip install

Another common stumble when building an ML environment is mixing up uv add and uv pip install. They look similar but play clearly different roles.

• uv add torch — records the dependency in pyproject.toml and updates uv.lock. Use this when you want a reproducible project.
• uv pip install torch — a pip-compatible interface that just drops the package into .venv. It does not touch pyproject.toml.

The mistake I make most often is running uv pip install to test something, feeling satisfied it works, and then forgetting to write the dependency back into pyproject.toml. I only notice when uv sync on another machine comes up without torch. A simple rule keeps this from biting: use uv pip install while experimenting, and uv add to commit the dependency once it's confirmed.

Loosen index-strategy When Resolution Is Too Strict

By default, uv uses a fairly strict resolution that prefers "the first version found in the first index." For packages that span multiple indexes — like PyTorch, which lives on both PyPI and pytorch.org — this default can be the actual cause of a "no solution found" error.

# Look across all indexes before deciding on a version
uv add torch --index-strategy unsafe-best-match

The unsafe name sounds alarming, but the actual behavior is just "consider all indexes before resolving." It's also useful in environments that mix an internal mirror with PyPI. If the Error 2 conflict is happening around CUDA-build torch, try this flag first — it often resolves things in one shot.

What I Learned the Hard Way

When I was setting up a local preprocessing step to classify images for a wallpaper app on my Mac, I lost half a day to exactly these torch and pyarrow build issues. What finally worked was three things: pinning Python to 3.11, installing the CPU build of torch first, and pulling pyarrow as a pre-built wheel with --prefer-binary — which is, in the end, the same order this article lays out.

The error messages look long and complicated, but the root cause almost always falls into one of three buckets: Python version, index selection, or build toolchain. Figuring out which bucket you're in first is, counterintuitively, the fastest path through. If this saves you even a little of the time I burned, I'll be glad.