Migrate to uv and Ruff Before OpenAI Ships Its Own

Tooling that was already winning is about to land inside the biggest AI lab in the world. OpenAI is acquiring Astral, the company behind uv and Ruff. The deal makes strategic sense. uv is the fastest Python package manager by a wide margin. Ruff has eaten flake8, isort, pylint, and most of black inside two years. Both tools are written in Rust, both are roughly 10 to 100 times faster than what they replaced, and both have already become defaults in the projects that pay attention.

The acquisition does not change the tools today. It changes their trajectory. Whatever OpenAI ships as its official Python developer experience will start from uv and Ruff. If you are still running pip and black in 2026, you are about to be on the wrong side of the default. Migrate now, while the migration is purely a productivity win, before it becomes a checkbox you have to tick.

This guide walks through the migration for a typical FastAPI project, with before and after configs and the GitHub Actions changes you actually need.

Why this matters operationally

A typical FastAPI service has 30 to 60 dependencies. With pip and a virtualenv, a clean install takes 25 to 45 seconds. With uv, the same install takes under 2 seconds. CI pipelines that used to spend 90 seconds just resolving and installing dependencies now spend 5. Across a team running CI 200 times a day, that is hours of compute and developer wait time eliminated.

Ruff replaces a stack: black for formatting, isort for import order, flake8 for linting, pylint for deeper checks, autoflake for unused imports, pyupgrade for modernization. Ruff does all of it in one binary, in milliseconds, with one config file.

The before picture

Here is the typical FastAPI project setup most teams have. requirements.txt for pinned versions, requirements-dev.txt for dev dependencies, separate configs for black, isort, flake8, and pylint, a pre-commit hook that takes 8 seconds to run.

project/
  requirements.txt
  requirements-dev.txt
  setup.cfg          # flake8, pylint config
  pyproject.toml     # black, isort config
  .pre-commit-config.yaml
  .github/workflows/ci.yml

requirements.txt:

fastapi==0.115.0
uvicorn==0.32.0
pydantic==2.9.2
sqlalchemy==2.0.36

The CI workflow:

- name: Install
  run: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt -r requirements-dev.txt
- name: Lint
  run: |
    flake8 app/
    black --check app/
    isort --check app/
- name: Test
  run: pytest

This works. It is also slow, fragmented, and full of tool-specific quirks. Each tool has its own opinions about line length. Each tool has its own ignore syntax. Onboarding a new developer takes 20 minutes of "wait, why is there both setup.cfg and pyproject.toml" explanations.

The after picture

One pyproject.toml with everything. uv handles dependencies. Ruff handles formatting and linting. The configs live together. A single uv lock file gives you fully reproducible installs.

[project]
name = "myapp"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "fastapi>=0.115.0",
    "uvicorn>=0.32.0",
    "pydantic>=2.9.2",
    "sqlalchemy>=2.0.36",
]

[dependency-groups]
dev = [
    "pytest>=8.0",
    "pytest-asyncio>=0.24",
    "ruff>=0.7.0",
    "mypy>=1.13",
]

[tool.ruff]
line-length = 100
target-version = "py312"

[tool.ruff.lint]
select = [
    "E", "F", "W",     # pyflakes, pycodestyle
    "I",                # isort
    "N",                # pep8-naming
    "UP",               # pyupgrade
    "B",                # flake8-bugbear
    "SIM",              # flake8-simplify
    "RUF",              # ruff-specific
]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"
indent-style = "space"

That is the whole tooling config. No setup.cfg. No separate black config. No flake8 config in three different places. One file.

The migration steps

Step 1: Install uv. One command, no virtualenv required.

curl -LsSf https://astral.sh/uv/install.sh | sh

Step 2: Initialize uv in your existing project. uv will read your existing requirements.txt files and bring them into pyproject.toml.

cd myapp
uv init --no-readme --package
uv add $(cat requirements.txt | xargs)
uv add --dev $(cat requirements-dev.txt | xargs)
uv lock

Step 3: Install Ruff and run it against your codebase. Ruff has a black-compatible mode by default, so the format pass should be a near no-op if you were already using black.

uv add --dev ruff
uv run ruff check --fix app/
uv run ruff format app/

Step 4: Delete the old config files and the requirements.txt files. Commit pyproject.toml and uv.lock. Update your README to use uv commands.

rm requirements.txt requirements-dev.txt setup.cfg
git add pyproject.toml uv.lock
git rm requirements.txt requirements-dev.txt setup.cfg

CI updates for GitHub Actions

This is where you see the speed gain land. The new workflow uses the official setup-uv action, which caches the uv binary and the package cache, then runs ruff and pytest through uv run.

name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v4
        with:
          enable-cache: true
          cache-dependency-glob: "uv.lock"
      - name: Install
        run: uv sync --all-extras --dev
      - name: Lint
        run: |
          uv run ruff check app/
          uv run ruff format --check app/
      - name: Type check
        run: uv run mypy app/
      - name: Test
        run: uv run pytest

The setup-uv action caches both the binary and the resolved package set keyed on uv.lock. On a cache hit, the install step takes under a second. On a cache miss, it takes 3 to 5 seconds. Compare that to 30 to 60 seconds with pip and you see why teams that switch don't switch back.

What about Poetry, Pipenv, Hatch?

If you are on Poetry, the migration is even simpler. uv reads pyproject.toml in PEP 621 format directly. You translate the [tool.poetry.dependencies] section into [project.dependencies] and run uv lock. Most projects take 10 minutes. Pipenv and Hatch users follow the same pattern.

The teams that resist this migration usually do so because their CI scripts are deeply tangled with pip-specific behavior. Those teams should migrate first, exactly because they have technical debt that the speed of uv exposes and makes worth fixing.

The OpenAI angle

OpenAI buying Astral is not just a talent play. It is a signal that the lab views Python developer experience as core infrastructure for what they are shipping next. Codex, agent SDKs, the developer portal, the eventual on-device stuff. All of it benefits from a fast, reliable Python toolchain that they control.

What this means for you depends on how cynical you want to be. The optimistic read: uv and Ruff get even more investment, become more reliable, gain features faster. The cynical read: in 18 months there will be an "OpenAI recommended" config that ships out of the box with whatever they release, and being on the uv stack already will save you a forced migration.

Either way, the move now is the same move. uv and Ruff are better tools today, before any OpenAI integration. They will be more entrenched defaults in a year. Migrate while it is purely a quality decision. Do not wait until it is a compatibility decision.