Enhancement: add `upgrade --all` option

[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:

• https://github.com/pypa/pip/issues/4551
• https://github.com/pypa/pip/pull/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

[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 https://github.com/pypa/pip/issues/4551#issuecomment-2325495099

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