Why `uv add transformers` Fails Inside Antigravity, and How to Actually Fix It

You ran uv add transformers inside an Antigravity-managed Python project, and now the agent's terminal greets you with ModuleNotFoundError: No module named 'transformers'. Or worse, uv itself returns error: distribution transfomers was not found and refuses to add the package. If you have just started touching Hugging Face models from inside Antigravity, this is the wall almost everyone hits first.

I tripped over the exact same setup when I started prototyping local LLM workflows. The fix is rarely just one thing. It is usually a small mismatch between how uv resolves the package, which virtual environment Antigravity's terminal is reading from, and which exact distribution name PyPI expects. Walk through them in order and the failure almost always goes away.

Start by checking the spelling, even if you swear it is right

I have seen the query uv add transformers error transfomers not found in real search data. Look closely: it is transfomers with a missing "r". uv is strict against the registry, and one wrong character is enough to make it bail out.

$ uv add transfomers
error: Distribution `transfomers` was not found in the registry

I once spent ten minutes copy-pasting from a tutorial that had the typo baked in, then blamed my Python install. The correct spelling is transformers. Antigravity's agent occasionally inherits this typo from your prompt, so worth re-checking the exact command it ran.

# ✅ Correct
$ uv add transformers
Resolved 18 packages in 612ms
+ transformers==4.46.2

While you are there, watch out for the neighbouring Hugging Face packages people often install in the same breath: tokenizers (not tokeniser), accelerate (not accelerator), safetensors (not the singular safetensor). Keeping that list pinned somewhere has saved me more than once.

uv add succeeded, but import transformers still fails

This is the second most common scenario, and the most quietly frustrating one. uv add writes to your project's virtual environment in .venv/, but the Python that actually runs your code is a different interpreter that has nothing installed. From your shell's point of view, the package never arrived.

Two commands tell you everything you need:

$ which python
/usr/bin/python                                # System Python
$ uv run python -c "import sys; print(sys.executable)"
/Users/you/project/.venv/bin/python            # The Python uv is targeting

The trap is that if Antigravity's terminal launches before you activate .venv, anything you uv add after that will not appear in the running shell's import path. I burned half an hour on this before it clicked.

There are three ways out, in increasing order of how much I trust them on a multi-agent project:

# Option 1: wrap every run with uv run (my default)
$ uv run python script.py
 
# Option 2: activate the venv up front
$ source .venv/bin/activate
$ python script.py
 
# Option 3: a project script if pyproject.toml defines one
$ uv run my-script

I stick with option 1 across the board. The reason is operational: when you hand work off to an Antigravity agent in a separate session, prefixing with uv run removes any chance of it falling back to system Python. Activation-based workflows break the moment the agent opens its own shell, which it will.

Antigravity's agent runs in a shell that does not see your activation

You can run the script just fine in your own terminal, but the moment you ask the agent to "run the same script", you get ModuleNotFoundError. This happens because Antigravity spawns its agent shells independently. Whatever you sourced into your terminal is invisible to it.

The cleanest fix is to put the run path into the project itself. Either define a [project.scripts] entry, or commit a tiny runner script to the repo and tell the agent to use that.

# pyproject.toml
[project]
name = "my-llm-app"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
    "transformers>=4.46.0",
    "torch>=2.4.0",
    "accelerate>=1.0.0",
]
 
[project.scripts]
infer = "my_llm_app.cli:main"

# How the agent should be told to run it
$ uv run infer --prompt "hello"

As long as the agent invokes uv run infer rather than python script.py, it will always pick up the .venv copy of transformers. Once you start coordinating multiple Antigravity agents through the manager surface, this kind of accident multiplies, so it is worth standardising on uv run from day one.

The torch backend silently disagrees with your machine

uv add transformers resolved, the import works, but the moment you call pipeline(...) you get a RuntimeError. Nine times out of ten, the failure is on torch's side, not transformers'.

A pattern I see often on Apple Silicon:

# Crashes
from transformers import pipeline
pipe = pipeline("text-generation", model="meta-llama/Llama-3.2-1B")
# RuntimeError: MPS backend out of memory ...

# ✅ Pin the device explicitly
import torch
from transformers import pipeline
 
device = "mps" if torch.backends.mps.is_available() else "cpu"
pipe = pipeline(
    "text-generation",
    model="meta-llama/Llama-3.2-1B",
    device=device,
    torch_dtype=torch.float16,  # halves memory on MPS
)
print(pipe("Hello, ")[0]["generated_text"])
# Expected output: a short continuation like "Hello, world!..."

On a Linux box with an NVIDIA GPU, you need the CUDA build of torch. With uv, point at the right index:

# Example for CUDA 12.4
$ uv add torch --index https://download.pytorch.org/whl/cu124
$ uv add transformers

I once moved code that worked on my Mac straight to a Linux GPU server with device="mps" still hard-coded, and spent half a day blaming transformers before I noticed. Lift the device into an env var or a config file early; it pays off the first time you switch machines.

Hugging Face Hub is a separate trip from PyPI

A pattern I hear from teams using Antigravity behind a corporate proxy: the library installs cleanly, but model downloads time out. That is because transformers itself comes from PyPI, while the model weights are pulled from Hugging Face Hub through a different code path.

# Variables that usually need to be set behind a proxy
$ export HF_HUB_OFFLINE=0
$ export HTTP_PROXY=http://proxy.company.local:8080
$ export HTTPS_PROXY=http://proxy.company.local:8080
$ export HF_HOME=$HOME/.cache/huggingface  # or a shared mount

There is a separate guide on running Antigravity through a corporate proxy and firewall that goes into the firewall side. Because Antigravity's terminals and agents do not share a shell, putting these into .zshrc is not enough. Encode them in pyproject.toml or a .envrc so the agent picks them up too.

If you want to lock the environment to fully offline, set HF_HUB_OFFLINE=1 and pre-download what you need with huggingface-cli download. The local cache will satisfy subsequent loads even if the network drops.

A small note on uv add versus uv pip install

One pattern that catches people switching from pip is using uv pip install transformers and expecting it to update pyproject.toml. It does not. uv pip install is the Pythonist-friendly wrapper that mirrors classic pip semantics; it installs into the environment but leaves your project metadata untouched. uv add is the project-aware command that updates pyproject.toml and uv.lock so the dependency travels with your repo.

# Updates pyproject.toml and uv.lock — preferred for project deps
$ uv add transformers
 
# One-shot install that does NOT update your project files
$ uv pip install transformers

If your agent reproduces a fresh checkout and complains that transformers is missing, check whether the original setup ran uv pip install (transient) instead of uv add (committed). I have seen this exact divergence between a developer's local environment and a CI worker more than once.

When the failure is actually a Python version mismatch

A subtler cause that surfaces on long-lived projects: uv add transformers resolves to a wheel built for a Python version that does not match your project's interpreter. transformers typically supports a range of Python versions, but its dependency tree (notably tokenizers and safetensors) ships with pre-built wheels for specific minor versions. If your requires-python is set to a version that has no matching wheel, uv may fall back to a source build, fail to compile, and leave you with a partial install that imports incorrectly later.

# Pin the Python version explicitly
$ uv python pin 3.11
$ uv sync
$ uv add transformers

I hit this on a project where requires-python was floating at >=3.13 while half my dependencies still expected <3.13. Pinning to 3.11 unblocked everything in a single command. It is worth checking uv python list to see which interpreters uv has access to, then explicitly pinning one with uv python pin.

The shortest checklist that catches 95% of cases

If everything above still fails, run these in order. In my experience three is usually enough.

• uv pip list | grep transformers to confirm the package is actually present from uv's perspective
• uv run python -c "import transformers; print(transformers.__file__)" to confirm the loaded path is under .venv/
• uv lock to verify your lock file is intact (delete it and rerun if not)
• uv cache prune followed by uv sync --reinstall for a clean rebuild

When I asked an Antigravity agent to "set up the whole environment for me" and it broke, the second command was the one that exposed the problem every time. If __file__ points at system Python's site-packages, you have an environment problem, not a package problem.

The single most useful thing you can do today is run that one line: uv run python -c "import transformers; print(transformers.__file__)". The path it prints will tell you immediately whether you need to fix the install or fix the environment.