The problem

If you use uv, you probably know this. You run uv lock --upgrade, the lock file moves forward, and your pyproject.toml stays where it was. So the project still says httpx>=0.23 while it really runs 0.28. After a year or two the floors in pyproject.toml say very little about what the project actually needs.

uv has no command for this yet. The issue is astral-sh/uv#6794, "Upgrade dependencies in pyproject.toml (uv upgrade)". It was opened in August 2024, and on 2026-10-28 it had 537 👍. The right long-term place for this is uv itself. I wanted something I could use until then, so I built a small separate tool: floorup. It is not affiliated with Astral.

What it does, in one line: raise every version floor in pyproject.toml to the latest PyPI release, in one command, without touching anything else.

$ floorup --dry-run
bumped 5 dependencies in 0.195s; 1 exact pins unchanged
httpx>=0.23  ->  httpx>=0.28.1  (project.dependencies)
pydantic>=2.0,<3  ->  pydantic>=2.14.1,<3  (project.dependencies)
rich~=13.0  ->  rich~=13.9  (project.dependencies)
pytest>=7  ->  pytest>=9.1.1  (dependency-groups.dev)
ruff>=0.1.0  ->  ruff>=0.17.3  (dependency-groups.dev)

(That is real output from 2026-10-27. Your versions will be newer.)

The hard part: do not touch anything else

The first idea is easy: load the TOML, change the strings, write it back. The problem is the "write it back" part. People put comments next to dependencies, line up columns, choose single or double quotes, and leave blank lines on purpose. A tool that re-serializes the file will change some of that, and then the diff in your pull request is full of noise. I did not want a diff with even one unrelated line.

So floorup never re-serializes the file. It is written in Rust and uses toml_edit, but only to find things. It parses the file with ImDocument, which keeps the byte span of every value in the original text. (DocumentMut turns those into owned strings, which would force a full rewrite.) For each dependency string, floorup knows exactly where it starts and ends in the file.

Then there is a second, smaller parser for the requirement string itself (PEP 508). It also keeps spans: where the operator is and where the version is. Names, extras, markers and spaces are not touched. The edit at the end is a byte splice: take the original text, replace only the operator and version bytes, and keep the rest. That code is in src/edit.rs.

To check this, there is a function called preserves_unrelated_bytes. It removes the edited spans from the old text and from the new text, and checks that what is left is identical. The tests call it all over the place. If any byte outside an edited specifier changes, the test fails.

The tables it edits are [project] dependencies, [project.optional-dependencies], [dependency-groups], [tool.uv] dev-dependencies and [build-system] requires.

Version policy

Finding the newest version is the easy part. Deciding what to write is where most of the logic lives (src/policy.rs). Version parsing and comparison use the pep440_rs crate. The rules are:

• >=2.28 becomes >= the newest release.
• Caps (<, <=) are never widened. With >=2.0,<3, the floor moves to the newest release under the cap.
• ~=13.0 becomes ~=13.9. It stays in its series with the same number of components. --expand-compatible lets it leave.
• != is respected. The chosen release must satisfy every exclusion.
• >2.28 is rewritten to >= only when the new release is strictly newer and still satisfies the old >.
• ==1.2.3 stays unless you pass --bump-pins. ==1.* and === are never rewritten.
• A dependency with no bound stays without a bound. floorup never invents a bound you did not write.
• URLs, paths and VCS references are skipped. Extras and markers are carried through.
• Pre-releases and dev releases are ignored unless you pass --pre (or the specifier already names one). Fully yanked releases, releases with no files and local versions are ignored.

Speed

floorup reads versions straight from the PyPI JSON API with reqwest (blocking client, rustls). Lookups run in parallel with std::thread::scope and 16 workers by default (--jobs). Responses are cached on disk for one hour, and --offline uses only the cache.

The number I measured: on FastAPI's real pyproject.toml, 90 dependencies bumped in 0.165 s, with 0 unrelated diff lines. That is the median of 7 cold runs (empty cache, PyPI lookups included) on 2026-10-27, using scripts/measure.py from the repo. The full diff is in docs/fastapi-dry-run.diff, so you can check it yourself.

Tests

Since the whole point is "don't break my file", most of the work went into tests:

• Golden files. Real pyproject.toml files from FastAPI, Flask, httpx, Pydantic, Rich and Ruff, bumped against a fixed version grid so the expected output does not change when PyPI does.
• Property tests with proptest. Random but valid pyproject files, and the check is always that only specifier bytes changed.
• Adversarial tests for edge cases the golden files do not cover.
• A mocked PyPI server, so CI never talks to the network.
• An optional live test against real PyPI (FLOORUP_PYPI_LIVE=1 cargo test --test live).

CI runs cargo fmt --check, cargo clippy -D warnings and cargo test.

To be honest about how it was made: the initial implementation was written with an AI coding agent, and it is covered by the test suite above. The tests are the part I trust.

--check and --lock

Two flags made it useful for me beyond running it by hand.

--check writes nothing and exits 1 if any bound would move. You can run it on a schedule in CI, and a stale pyproject.toml fails a job the same way unformatted code does. --dry-run prints a unified diff (made with the similar crate) and writes nothing.

--lock writes the file and then runs uv lock. If locking fails, pyproject.toml is restored. This matters because of the main design choice: floorup reads the index, not a resolver.

Limitations

Reading the index directly is why it is fast and does not need a venv or a lock file. It is also the biggest limitation: each package gets its newest eligible release on its own, and nobody checks that all of them resolve together. Run uv lock or use --lock for that. Note that --lock restores pyproject.toml on failure, but not uv.lock if uv rewrote it before failing.

Other things it does not do:

• No uv workspace walk. Run it once per member (floorup packages/foo).
• requires-python is not edited.
• No Poetry tables.
• uv's constraint-dependencies, override-dependencies and build-constraint-dependencies are not edited.
• Only the PyPI JSON API. You can point --index-url at a mirror, but indexes that only serve the simple API do not work.

Other tools for the same gap

Several people have built tools for this, with different trade-offs, and one of them may suit you better. zundertj/uv-bump runs uv sync and sets the floors to what uv actually resolved, and it supports workspaces. Rezarys/uvbump also preserves formatting, has --check, runs uv lock by default and also edits uv's constraint and override tables. Alirex/uv_upgrade works from uv.lock with workspace support and rollback. duriantaco/fyn is a uv fork with its own resolver. rafaelsq/uvu is interactive, one package at a time. janusheide/uppd is pur-style, and poetry-plugin-up is the one to use for Poetry projects. The README has a table comparing them.

And when uv ships a native command for #6794, use that.

Try it

It needs Rust 1.88 or newer. There is no crates.io, PyPI or Homebrew release yet, so you install it from git:

cargo install --locked --git https://github.com/eurafaeldecarvalho/floorup
floorup --dry-run

Repo (MIT): https://github.com/eurafaeldecarvalho/floorup

The most useful thing you can send me is a pyproject.toml that floorup mangles, or a specifier where it gets the wrong answer. There are issue templates for that.