Upgrade dependencies in pyproject.toml (uv upgrade)

[KotlinIsland]

this will update the version pins in the pyproject.toml file

prior art:

• deno: https://deno.com/blog/v2.2#dependency-management
• poetry: https://github.com/MousaZeidBaker/poetry-plugin-up
• npm: https://docs.npmjs.com/cli/v10/commands/npm-update
  • npm-check-updates: https://www.npmjs.com/package/npm-check-updates

> uv upgrade
upgraded 10 dependencies in 0.001 seconds 🚀

why? when i want to update all the dependencies in a project, it can be tedious to manually search for and update each and every dependency. additionally, for application projects (not libraries), i like to be able to squizz the pyproject file for an easy overview of which dependencies are actually installed, not just some possible range

[nathanscain]

Does uv sync cover this use case?

Also, I'm pretty sure dependencies will also be updated during every uv run call by default.

[bjorhn]

I don't think uv sync can bump the pinned versions of every dependency to the latest available version, which I believe is what the issue creator is asking about. uv sync just downloads modules that match the pin, it doesn't change the pin.

This topic always ends up being confusing, people have different definitions of what it means to update or upgrade a dependency. 😅

[nathanscain]

Ahh, yes uv sync updates the environments but not the install specs.

Would it be recommended to not pin exact dependencies in the pyproject.toml - instead to use the lock file for tracking that?

pyproject.toml should track compatibility and uv.lock should track exact versions for deployments/reproducibility.

[bjorhn]

I suspect a lot of teams have a similar workflow to my team, which most project tooling has poor support for.

In the pre-Dependabot days, once a month or so we'd open up the project file on one screen and pypi on the other, then manually bump all the versions to the latest we could find. Then we'd install everything, read release notes, check what broke, and perhaps go back a version or two for some of the dependencies (which is why unpinning all the deps wouldn't work). After that we'd generate a new lock file.

Having an upgrade command would remove the manual labor of having to look up all the versions and editing the file for each individual dependency.

[Mazyod]

Poetry has a nice workflow by using poetry show --outdated rather than opening PyPI.

[akx]

uv upgrade-interactive would also be great, like yarn (v1):

[pythonweb2]

Use uv sync -U to update packages

[pythonweb2]

Although I will note that it would be nice to be able to see which packages are outdated, similar to pip list --outdated or the poetry show --outdated command which does the same thing.

[akx]

Although I will note that it would be nice to be able to see which packages are outdated,

That's tracked in #2150.

[johnthagen]

Like @KotlinIsland said, especially for applications it's really nice to be able to browse narrow ranges of your top level dependencies within pyproject.toml and have a tool automatically bump them for you so you don't have to go to PyPI and look at each top level dependency to see what the latest version is.

It's also important to be able to skip dependencies that the user has pinned to a specific version in pyproject.toml so that if you know you can't upgrade past a version, you can pin it in pyproject.toml until the issue is resolved upstream.

The old poetryup plugin had a --skip-exact flag for this

• https://github.com/MousaZeidBaker/poetryup?tab=readme-ov-file#usage

For more prior art, see npm-check-updates

• https://www.npmjs.com/package/npm-check-updates

It has a nice output UI:

(Long) discussion from the same feature requested in Poetry

• Suggestion: new command to bump versions of dependencies in pyproject.toml python-poetry/poetry#461

[krishan-patel001]

I agree this would be a really helpful feature, especially useful in PRs for tracking version increments. Its a lot easier to see these in pyproject.toml than a lock file

[daeh]

I'm also a big fan of yarn's yarn upgrade-interactive for interactively updating dependency versions in package.json and would love to see similar uv functionality for updating dependency versions in pyproject.toml.

[yhoiseth]

I use this tiny script. Works like a charm.

[wgordon17]

Is this intended to handle the following use case?

dependencies = [
    "httpx==0.27",
]

uv upgrade

dependencies = [
    "httpx==0.28",
]

(where 0.28.1 is the latest version of httpx as listed in uv tree --outdated)

Would it require something like uv upgrade --outdated [<package>] or uv upgrade --override [<package>] or similar?

Currently, even an ugly hack like

uv tree --outdated -d1 | grep "latest" | sed -E 's/.*── ([^ ]*) .*latest: v(.*)\)/\1==\2/' | xargs -I {} uv lock --upgrade-package {}

isn't working, because uv lock --upgrade-packages still attempts to satisfy the existing constraints. And the uv remove/uv add workaround doesn't address handling different dependency groups.

[yhoiseth]

@wgordon17

[The] uv remove/uv add workaround doesn't address handling different dependency groups.

You might be interested in @KotlinIsland’s improved version, as this should handle dependency groups.

[JakubDotPy]

Would this count as using uv?

uvx pdm update --unconstrained

[wgordon17]

🤔 Does --unconstrained then write the difference back to pyproject.toml, i.e., the updated packages? Or is pyproject.toml now lagging behind?

[Goldziher]

Would this count as using uv?

uvx pdm update --unconstrained

PDM is excruciatingly slow...

The current work around with a script that uses UV to remove and readd deps is many times faster

[lucebert]

+1

[samypr100]

For more prior art, see npm-check-updates

* https://www.npmjs.com/package/npm-check-updates

I'm a fan of npm-check-updates personally, especially because you can filter via -t for major, minor, and patch changes at direct and transitive layers and bump at the semver tiers which for application development is quite nice. I originally opened #2745 with the desire of one day having semver filtering in uv for this kind of purpose.

For poetry, I've used a combination of poetry show --outdated with -T to filter for direct dependencies. I've also used pip-check-updates in the past with poetry export and uv, but nothing quite like the ergonomics of ncu exists to my knowledge.

[kedvall]

Hi guys, as a temporary solution I've wrote a small program to sync the minimum versions of top-level dependencies.
Please note that since it's intended to be a temporary solution it's not very robust or feature-rich and there's a few known issues I haven't had time to solve.

Anyways, hope it might be helpful! Feel free to check it out: https://github.com/kedvall/pysync.

[domWalters]

I suspect a lot of teams have a similar workflow to my team, which most project tooling has poor support for.

In the pre-Dependabot days, once a month or so we'd open up the project file on one screen and pypi on the other, then manually bump all the versions to the latest we could find. Then we'd install everything, read release notes, check what broke, and perhaps go back a version or two for some of the dependencies (which is why unpinning all the deps wouldn't work). After that we'd generate a new lock file.

Having an upgrade command would remove the manual labor of having to look up all the versions and editing the file for each individual dependency.

For anyone using nvim, there is a completer that might speed up this process called cmp-pypi which will autocomplete available versions of a package read from the PyPi index.

Basically just curls the index for the package and pulls out the available versions.

I recently improved it by adding the ability to search the optional dependencies.

Note: It doesn't currently sort into version order.

[Goldziher]

So, I used a variation of the script discussed above for this. But now I am working inside a monorepo with multiple UV modules, and writing a script for this has become increasingly complex.

I think this has to be a part of the built-in uv command, and I frankly don't see why this should be complex - it's rather smallish.

The question is, is there interest and willingness from the uv maintainers? If there is, I or someone else can contribute to this.

[aretrace]

Interested in this as well.

[tdamsma]

I bit gross, but this bash command works for me. It removes and then adds all dependencies

deps=$(sed -n '/^\s*dependencies\s*=\s*\[/,/^\s*]/p' pyproject.toml | \
  grep -vE '^\s*dependencies\s*=\s*\[|^\s*\]' | \
  sed -E 's/[",]//g' | \
  sed -E 's/[<>=!~].*//' | \
  grep -vE '^\s*$' | \
  xargs)

bash -c "uv remove $deps && uv add $deps"

[reneleonhardt]

I bit gross, but this bash command works for me. It removes and then adds all dependencies

Nice! Now optional dependencies would be good (every line is a list) 😅
https://github.com/pipecat-ai/pipecat/blob/main/pyproject.toml#L41

[trevorstr]

I just tried to manually change a dependency version in pyproject.toml and then executed uv run, and it still used the old package version.

I updated browser-use to include the version specifier, whereas previously it didn't.

dependencies = [
    "boto3>=1.37.36",
    "browser-use==0.1.45",
    "watchtower>=3.4.0",
]

After running uv run <script>, I checked the ./lib/python3.13/site-packages directory, and the new package version was not in there.

It's kind of deceiving (unintentionally) for uv to simply ignore the updated version specifier, and continue using the old version, when the developer has explicitly updated pyproject.toml.

That is my use case for needing the upgrade sub-command.

[Goldziher]

the uv-bump solution above works pretty well. Perhpas it can be published?

[reneleonhardt]

After running uv run <script>, I checked the ./lib/python3.13/site-packages directory, and the new package version was not in there.

Do you mean:

• uv.lock contained browser-use==old.version.x (<0.1.45)
• pyproject.toml changed from "browser-use" to "browser-use==0.1.45" (manual update)
• uv run didn't change uv.lock to browser-use==0.1.45
• [Please don't use the latest version, then you will see better if your constraint has been respected. For example 0.1.44]

I don't think uv run changes the lockfile, did you call uv lock --check and uv lock --upgrade-package browser-use?
https://docs.astral.sh/uv/reference/cli/#uv-lock--upgrade-package

There should be no other "output" files laying around (only pyproject.toml and uv.lock).
My problem was that when requirements.txt existed while I was exporting it (overwriting the whole file), uv wouldn't update minor versions even if they were allowed by constraints.

And pay attention to the log output, other dependencies can influence the outcome (preventing updates).
So in your case a single dependency browser-use would be best 😅

[Lauszus]

Here is a shell script for upgrading all dependencies:

#!/bin/bash -e

# Allow to specify a directory as the first argument
dir=.
if [ $# -gt 0 ]; then
  dir=$1
fi

# Sync the current project
uv --directory "$dir" sync --refresh --locked

# Get all the outdated dependencies
outdated="$(uv --directory "$dir" pip list --outdated --format json | jq -r '.[] | {name,version,latest_version} | join(" ")')"

# Iterate over all of them
upgraded=false
while IFS= read -r line; do
    [ -z "$line" ] && continue
    IFS=' ' read -r name version latest_version <<< "$line"
    # Check if they are actually present in pyproject.toml or a dependency of a dependency
    if grep -q "$name" "$dir/pyproject.toml"; then
        echo "Upgrading $name $version -> $latest_version"
        sed -i -E "s/$name( ?[~=>]?[>=] ?)$version/$name\1$latest_version/" "$dir/pyproject.toml"
        upgraded=true
    fi
done <<< "$outdated"

# Re-lock the project if a dependency was upgraded
if $upgraded; then
    uv --directory "$dir" lock
fi

[ssteinerx]

@Lauszus -- great idea, but unfortunately, it misses what is, I would think, a pretty common case.

If the installed version is the latest (because the version spec in pyproject.toml allows it), then uv pip list --outdated won't pick it up since the latest version is in the .venv.

For example, if "pydantic>=2.8.0", is in pyproject.toml, then uv sync --refresh will upgrade to "pydantic=2.11.4" in the .venv.

uv pip list --outdated won't pick it up because the .venv has the latest version and, so, nothing will happen.

@tdamsma's script above will replace the old version spec with the new in this case (by removing, then reinstalling), but that might not always be right, either.

I think the only reasonable way to really do this is to snag all the version specs out of pyproject.toml, snag them from a refreshed .venv, compare, then ask the user what they want to do (or have a config for this behaviour).

Also, there are some ambiguities around how to update the spec e.g. do you use >= just because that's what was there before, or do you restrict it to = to make sure the update check is more obvious/accurate/narrower in the future?

Regardless, I don't know about you, but I sure wouldn't want to do that in a bash script ;-).

[Lauszus]

@Lauszus -- great idea, but unfortunately, it misses what is, I would think, a pretty common case.

If the installed version is the latest (because the version spec in pyproject.toml allows it), then uv pip list --outdated won't pick it up since the latest version is in the .venv.

For example, if "pydantic>=2.8.0", is in pyproject.toml, then uv sync --refresh will upgrade to "pydantic=2.11.4" in the .venv.

uv pip list --outdated won't pick it up because the .venv has the latest version and, so, nothing will happen.

@tdamsma's script above will replace the old version spec with the new in this case (by removing, then reinstalling), but that might not always be right, either.

I think the only reasonable way to really do this is to snag all the version specs out of pyproject.toml, snag them from a refreshed .venv, compare, then ask the user what they want to do (or have a config for this behaviour).

Also, there are some ambiguities around how to update the spec e.g. do you use >= just because that's what was there before, or do you restrict it to = to make sure the update check is more obvious/accurate/narrower in the future?

Regardless, I don't know about you, but I sure wouldn't want to do that in a bash script ;-).

Ahh I see your point. It won't work for >= or >. I don't use that for my application, so it's not a problem in my case.

This was just a quick script I did to get it working for me since Dependabot keeps breaking, so wanted to share it in case somebody else might find it useful :)

[zundertj]

the uv-bump solution above works pretty well. Perhpas it can be published?

I have published it here: https://pypi.org/project/uv-bump/.

[zundertj]

I think the only reasonable way to really do this is to snag all the version specs out of pyproject.toml, snag them from a refreshed .venv, compare, then ask the user what they want to do (or have a config for this behaviour).

Also, there are some ambiguities around how to update the spec e.g. do you use >= just because that's what was there before, or do you restrict it to = to make sure the update check is more obvious/accurate/narrower in the future?

This is why in uv-bump I decided to define dependencies with >= and let the UV resolver do its thing. If you want to pin, you can define a dependency version with == instead, and it will pin as intended. Same for holding off a major version upgrade, you can just say plotly>=5.1.0,<6 with the normal syntax and version 6 wont be installed. The versions on >= in the pyproject.toml will still be updated, i.e. the whole purpose is to upgrade and not allow falling back to older versions in the future, so it is still possible to see which version is actually used, it is just slightly less pleasant on the eyes than ==. In return, it does completely remove the ambiguity on upgrading and does not require a separate interface where you need to ask the user what to do for each dependency, i.e. does == mean "please upgrade" or does == mean "please pin on this version" for each dependency in the context of an "upgrade" command.

[sterliakov]

I'd appreciate a workflow similar to pnpm update -i -L: interactive, ignoring version constraints. That's extremely helpful when you have to deal with a pyproject.toml with arbitrary constraints: you can just compare "current" vs "latest" for every package and pick packages you're going to update now.