Skip to content

Did pip 26 close the gap with uv?

April 24, 2026·Tim Hopper
uv pip packaging

pip 26.0 closed two of uv’s clearest feature gaps in January: PEP 723 script installs and a datetime-based package filter that mirrors uv’s --exclude-newer. The October 2025 Hacker News thread that kept circling back to “pip has quietly caught up” now reads less contrarian than it did at the time, and the OpenAI acquisition of Astral in March changes the “is this safe to depend on” calculus at the same time.

Review pip’s 2025 to 2026 releases

Four pip releases have landed since April 2025, and the first three narrowed gaps uv was best known for:

  • pip 25.1 (April 2025) introduced the experimental pip lock command for PEP 751 lockfiles and --group for PEP 735 dependency groups.
  • pip 25.2 (July 2025) turned on automatic download resumption for flaky networks.
  • pip 25.3 (October 2025) started using PEP 658 separate-metadata files during pip lock and pip install --dry-run, so those commands no longer need to download full wheels when that metadata is available.
  • pip 26.0 (January 2026) added --requirements-from-script for PEP 723 inline script metadata, --uploaded-prior-to for datetime-based filtering (functionally equivalent to uv’s --exclude-newer), and --use-feature inprocess-build-deps for in-process build dependency installation.

Both pip 26 features work end to end. Saving a self-contained script:

demo.py
# /// script
# requires-python = ">=3.10"
# dependencies = [
#     "cowsay>=6",
# ]
# ///
import cowsay
cowsay.cow("hello from pip 26 and PEP 723")

Then installing its declared dependencies with pip 26.0.1:

$ pip install --requirements-from-script demo.py
Collecting cowsay>=6
  Using cached cowsay-6.1-py3-none-any.whl.metadata (5.6 kB)
Using cached cowsay-6.1-py3-none-any.whl (25 kB)
Installing collected packages: cowsay
Successfully installed cowsay-6.1

That closes one of uv’s most visible gaps for single-file scripts. The --uploaded-prior-to flag delivers the other half of the news:

$ pip install --uploaded-prior-to 2022-01-01 requests
...
Successfully installed certifi-2021.10.8 charset-normalizer-2.0.9 idna-3.3 requests-2.26.0 urllib3-1.26.7

The result is an older requests release with a correspondingly older dependency set, the same kind of reproducibility cutoff uv’s --exclude-newer provides.

pip lock is real too. Against a one-line reqs.txt containing httpx:

$ pip lock -r reqs.txt -o pylock.toml
Collecting httpx (from -r reqs.txt (line 1))
...
$ head -2 pylock.toml
lock-version = "1.0"
created-by = "pip"

Audit what’s still uv-only

The gap is narrower, not gone. Several capabilities stay uv-only in April 2026:

Manage Python itself. uv python install 3.13 downloads and manages a Python interpreter. pip does not, by design. pyenv or a system package manager handles that separately.

Replace pipx. uvx ruff check . runs a tool in an ephemeral environment in one command. pip has no equivalent; pipx or a fresh venv fills the role.

Run scripts without activation. uv run script.py ensures the virtual environment exists, syncs it against the lockfile, and executes the script, all in one call. pip has nothing at that layer.

Ship a cross-platform lockfile. pip lock --help labels the command “EXPERIMENTAL” and its output “only guaranteed to be valid for the current python version and platform.” uv’s default uv.lock is a universal lockfile that can cover multiple platforms and Python versions in one file.

Support wheel variants. uv has experimental support for the wheel variants proposal, which unblocks CPU-microarchitecture-specific and GPU-specific wheels. pip has not adopted it yet.

Workspaces. [tool.uv.workspace] manages multiple packages under one lockfile. pip has nothing analogous.

Speed. Astral’s benchmarks show uv installing dependencies 10 to 100 times faster than pip on warm caches. That gap is not a PEP away from closing, because pip’s architecture was not built for the parallelism and content-addressed caching uv relies on.

Rethink the risk calculus

The October 2025 HN thread carried a second argument alongside the feature debate: whether Astral, as a VC-backed company, was safe to build on. Commenters cited the Terraform-to-OpenTofu fork as the cautionary tale. That concern looks different than it did six months ago. OpenAI acquired Astral in March 2026, and the Astral team joined OpenAI’s Codex group. uv, ruff, and ty stay MIT-licensed, but they’re now sustained by a single AI lab rather than an independent company.

Whether that is better or worse depends on the failure mode you care about. The acquisition lowers one risk and raises another: OpenAI is less likely than a startup to disappear, but uv and ty are now tied more closely to one vendor’s priorities. pip carries the opposite tradeoff. Its governance is broader, but consensus maintenance slows architectural change.

Pick the right default for your project

If you’re already on uv, stay on uv. The speed gap persists and the feature delta still favors it, so switching back gives up more than it buys.

If you’re already on pip, or you’re choosing tools for a small or policy-constrained project, pip 26 is a stronger default than pip was in 2024. pip install, pip lock, pip install --group, and pip install --requirements-from-script now cover much of the ground that used to require pip-tools plus custom glue. Pair pip with venv and you have a usable stack.

For most new projects, uv still wins and the handbook still recommends it. If minimizing tools and vendor dependence matters more than speed and workflow breadth, pip is now a more defensible choice than it was six months ago.

Learn more

Last updated on
How Astral Uses Its Own Tools

Please submit corrections and feedback...