Add option to upgrade all packages in the environment, e.g., upgrade --all

[ikrommyd]

Something missing from pip is the ability to do upgrade --all like conda can do update --all in an environment.
Wrappers around pip that do this are oftentimes slow because python. Given that you already have some resolution strategies available, it would be really nice to see something like that. And it's also gonna be very fast in your case I believe.
The exact resolution strategy for something like that is up for discussion but I think resolution strategies like the one conda uses have been liked by the community.

[kdeldycke]

Relates to:

• Add an upgrade-all command pypa/pip#4551
• added upgrade-all command pypa/pip#10491

[zanieb]

Thanks! We should also clarify how pip install --upgrade is different than this in our documentation.

[sh-shahrokhi]

Hi, just wanted to add my voice for this one. Thanks.

[msminhas93]

This would be a great feature! Any updates?

[zanieb]

Hi, please just upvote the original post with 👍 if you want to see this. Otherwise we'll report back with any updates and would appreciate if the thread was focused on substantive discussion.

For this to move forward two things need to happen:

• A contributor willing to prototype it needs to come forward, this could be someone from the Astral team but we currently have other priorities.
• We need to answer some design questions, drawing a lot from the discussion over in pip, e.g.
  • Why isn't this being implemented in pip?
  • What is the desired behavior? Is there more than one expectation?
  • What is the main user-story for this? What use-cases are we addressing?

[dlasusa]

I would really love to see this feature added. I'm not sure if it's helpful, but I can describe how I currently update the packages in my virtual python environments. These are all run from an activated venv. In this case I have an environment for some polars projects.

I first run:

pip list --outdated

Which produces a list:

Package   Version Latest  Type
--------- ------- ------- -----
ipykernel 6.29.3  6.29.4  wheel
ipython   8.22.2  8.23.0  wheel
polars    0.20.16 0.20.18 wheel

This example is a mercifully short list since Polars doesn't have other Python dependencies. Plus, since it's a playground for testing one off things I want to try in polars, I don't have a ton of packages in this environment....but this list can get very long for larger projects (which is time consuming to manually update)

I'll then go one by one running (for example):

pip install --upgrade polars

There are times I'm unable to update all the packages. Usually if I have a failure, it's because pip can't find a suitable package/version. Depending on how critical the package is, or if it has new functionality that will be useful in a project, I may create an entirely new venv and do a new pip install ... on all the packages I need. I just updated all the packages in this example, and none failed, so I'm unable to provide more details about what I failure would look like. Basically, it's a dependency resolution failure.

@zanieb To answer some of the questions you listed (granted these are just MY opinion or my use case)

Why isn't this being implemented in pip?

This is a great question and something I've often wondered as well! I've come across both pip-tools and pip-review which is/was a fork of pip-tools and I think it's no longer maintained.
More reading: https://stackoverflow.com/questions/2720014/how-to-upgrade-all-python-packages-with-pip

What is the desired behavior? Is there more than one expectation?

The simple version of what I would want: simply update all the packages in the environment, and report what was/wasn't updated:

2 Packages Updated:
ipython   8.22.2  -> 8.23.0 
polars    0.20.16 -> 0.20.18

1 Package Not Updated:
ipykernel 6.29.3  No suitable version found

I'm of course open to other ideas too.

What is the main user-story for this? What use-cases are we addressing?

I'm not sure if it's just the work I do, but I'm often seeing new functionality in packages and/or I just like to stay current. Especially right now with many tools being updated/written in Rust, so I like to try out different things and see where development is at. I've never done (nor would I plan to) and "update all" in production. Though if enough tools are written in Rust and don't have Python dependencies, maybe much of this goes away?

Apologies if any of that is unclear. Just let me know if I can further clarify anything.

Thanks!!

[jvdavim]

I'm interested in this feature too. I don't know if it would help, but I'm currently updating the packages using:

rm uv.lock
uv lock
uv sync

Edit:

As commented by @bryant1410 and @D1no, I agree it's better:

uv lock --upgrade
uv sync

It works fine if using the uv as project manager.

[msminhas93]

Hi, please just upvote the original post with 👍 if you want to see this. Otherwise we'll report back with any updates and would appreciate if the thread was focused on substantive discussion.

For this to move forward two things need to happen:

• A contributor willing to prototype it needs to come forward, this could be someone from the Astral team but we currently have other priorities.

• We need to answer some design questions, drawing a lot from the discussion over in pip, e.g.

  • Why isn't this being implemented in pip?
  • What is the desired behavior? Is there more than one expectation?
  • What is the main user-story for this? What use-cases are we addressing?

The request for a uv update command to upgrade all packages is rooted in the fact that uv is more than just a package manager - it also handles environment management like conda, micromamba, and poetry.

These tools already offer similar functionality:

• conda/micromamba: conda update --all or micromamba update --all
• poetry: poetry update

This point talks about why it makes more sense to implement it at the higher level tool instead of pip pypa/pip#4551 (comment)

The primary use case is for development environments, particularly in fields like deep learning or data science, where frequent package updates are necessary.

[bryant1410]

How is this different from

uv lock --upgrade

?

[ikrommyd]

How is this different from

uv lock --upgrade

?

Am I mistaken or would this only apply to cases where you're using uv to manage your project. When I first opened the issue on day 1 of uv release I was thinking of an upgrade --all option to a generic python venv in a similar way conda has upgrade --all for a conda environment.

[D1no]

Yeah please add an update or upgrade like all package managers under the sun so normal engineering peasants like me don't need to do this odd mental gymnastics. Preferably a simple

update command that actually updates the version strings in the pyproject.toml for explicitness

• update packagename
• update -> leads to selection which packages to update
• update --all -> updates all of them

instead of having to do
uv lock --upgrade
uv sync
manually type

[yhoiseth]

I use this tiny script to upgrade all dependencies to their latest version regardless of what is specified in pyproject.toml.

[johnthagen]

update command that actually updates the version strings in the pyproject.toml for explicitness

This specific part of your request is tracked in

• (🎁) Add a command to "upgrade" dependency constraints in the pyproject.toml #6794

[ssbarnea]

If uv pip list --outdated would have supported a plain format, this could be seen as a decent workaround:

uv pip list --outdated --format=plain | uv pip install -U

My current workaround for this looks like:

uv pip list --outdated --format=json | jq '.[].name' | xargs -I {} uv pip install --system -q -U {}

[WilliamStam]

uv lock --upgrade
uv sync

seems to do what is required. but please can this be added as an alias type thing in uv?

uv update

got used to pdm update. whenever we work on a project we upgrade the dependencies to their latest patch version ie

dependencies = [
    "sqlalchemy-utils==0.41.*",
    "SQLAlchemy[asyncio]==2.0.*",
    "toml==0.10.*",
    "uvicorn==0.20.*",
]

so being able to "update" them all is very useful. i just found the uv lock --upgrade and sync thing now. but i can guarantee i will have forgotten about it next time i need it lol.

thanks for the project! its insanely fast

[yrro]

uv lock --upgrade
uv sync

seems to do what is required. but please can this be added as an alias type thing in uv?

uv update

Various package managers have overlapping and/or conflicting definitions of the word update and upgrade and I'd prefer to not have to add another one to the Rosetta stone. Really sorry to bike shed but good UI is important to me.

If existing commands are sufficient then I'd rather the documentation be updated to make it clear what the right commands are. I find it all a bit confusing, especially (and this isn't uv's fault itself) coming over from Poetry which seems have both poetry sync --lock and poetry lock --sync...

That said, hopefully someone can chime in here if I'm wrong:

uv sync --upgrade will both upgrade the packages in the lockfile to reference the latest compatible versions specified in the project's dependencies (equivalent to uv lock --upgrade), and also bring the project's venv's packages in sync with the new lockfile (equivalent to uv sync). So that is probably the command to document (unless I've misunderstood what you're trying to accomplish).

And to check if there are updates, I use uv lock --upgrade --locked, which doesn't tell you which packages are outdated, just whether any outdated packages exist. uv sync --upgrade --locked will do that & also bring the venv in sync if it's not already in sync for whatever reason.

[heliocastro]

And how about on sync pyproject with uv.lock after uv lock --upgrade ?

[krishan-patel001]

And how about on sync pyproject with uv.lock after uv lock --upgrade ?

I like the idea of this, wouldn't break the existing functionality then

[yrro]

And to check if there are updates, I use uv lock --upgrade --locked, which doesn't tell you which packages are outdated, just whether any outdated packages exist. uv sync --upgrade --locked will do that & also bring the venv in sync if it's not already in sync for whatever reason.

... or at least I used to. It seems now uv lock --upgrade --locked fails with error: the argument '--upgrade' cannot be used with '--check' which is... confusing. And uv sync --upgrade --locked fails with error: the argument '--upgrade' cannot be used with '--locked', which at least matches the options I specified on the command line... but neither tell me why this is no longer possible.

Perhaps uv lock --upgrade --dry-run is the replacement? But unfortunately, this exits successfully if there are packages to update, so it's no good for checking if there are upgradable packages.

[zanieb]

--locked is an alias of --check in uv lock, but I don't think we can distinguish between which was provided.

While I'm not sure it's the best way to solve this problem, I'm fine with allowing --upgrade --check.

See #10273 for the motivation behind making those options conflict.

[yrro]

Thanks. --upgrade --check would make sense to me, but there is overlap with --upgrade --dry-run; if --dry-run and --check were mutually exclusive then that would resolve and it would be clear that --check is expected to fail of there are pending updates, whereas --dry-run is expected to succeed.