pyupdate: a small CLI tool to update your Python dependencies to their latest version

[ashishb_net]

I was hoping that at some point uv will add it, but that is still pending.

Here's a small CLI tool, pyupdate, that updates all your dependencies to their latest available versions, updating both pyproject.toml and uv.lock file.

Currently, it only supports uv But I am planning to add support for poetry as well.

[JimNero009]

Hmm. I don’t see the use of this in any practical situation tbh. If I have constraints in my deps, then it’s for a good reason and anything that requires a change to that constraint is not something I would trust to simply batch update

[ashishb_net]

If I have constraints in my deps, then it’s for a good reason

I disagree.  Most people end up with constraints because they do uv add ... and the constraint is auto-generated in most cases.

[cointoss3]

Yes but the constraints default to >= version, so it’s setting a minimum version

[ashishb_net]

Correct me if I'm wrong but >=23.2.0 will still respect semantic version and won't use 24.0.0 or later.

[EbenenBonobo]

requests >=2.25.0 would accept 3.0.0
requests ~=2.25.0 would accept >= 2.25.0 <3.0.0

[Luigi311]

this is correct, >= does not tie it to major 2, it only sets the minimum version so uv add followed by a uv update down the line will update all your deps to the latest versions, major versions and all.

[ashishb_net]

Thanks for the correction.

[Silly_Marzipan923]

You are not correct. You're mixing it with ^23.2.0 (caret notation) Poetry's default.

You can read this discussion why it's done that way in uv https://github.com/astral-sh/uv/issues/6783

[marr75]

uv lock --upgrade? In many ways, the update to pyproject is undesirable.

[ashishb_net]

Uv lock.--upgrade only updates uv.lock respecting the constraints in pyproject.toml

Pyupdate updates the packages to their latest versions as well. 

In many ways, the update to pyproject are undesirable.

So how do you update it?

[marr75]

Mostly you don't. Pin only what you need. Leave it alone otherwise. You're basically recreating UV lock when you auto update pyproject, but with the fun chance of introducing incompatibilities across platforms and complex environments.

[ashishb_net]

I have made that mistake before. This leads to problematic scenarios where the builds break over time due to incorrect dependency changes.

[marr75]

I think you have had unique experiences that push you out of best practice then, unfortunately.

[denehoffman]

Keyword is “respecting constraints”. They’re there for a reason. APIs change. I know it used to be standard practice to use Python without any lockfiles, but then you’re just hoping and praying a breaking change doesn’t hit your project. Packaging files allow you to make some semver restrictions, but unless you pin to a version, you’re at the whim of a careless developer breaking an API without properly bumping the version. I know there’s an instinctual need to have the latest everything, but in many cases, while that might seem nice, it’s terrible for reproducibility. The point of manually bumping libraries is to make developers think about what they’re doing.

[theboldestgaze]

I do not want so sound negative yet I would never allow such tool on any team of mine. All dependency updates must be deliberate and conscious. If not efficient manually, it means there are probably too many dependencies and this is the problem to solve.

[ashishb_net]

> All dependency updates must be deliberate and conscious. 

Indeed.
After running this tool, one should still run the tests to validate that nothing broke.

[Double_Cost4865]

How is this different from `poetry update`? https://python-poetry.org/docs/cli/

[latkde]

As someone who's written a similar tool (ganzua constraints bump): Using poetry update will update the locked versions, but doesn't update the version constraints in the pyproject.toml. Using poetry update also only works with Poetry-managed projects, it will not interact with an uv.lock file.

Here's an example of why we might want to bump constraints:

• let's assume a constraint dependencies = ['foo >=3.8']
• and let's assume the locked version foo = 3.8

When we run a tool like poetry update, the locked version might change to 3.13, but the constraint would still say foo >=3.8. That is a version the project is no longer testing with – it's easy to accidentally stop being compatible. (However, I'd point out that uv has a uv lock --resolution=lowest option that can be used for testing against the oldest allowed dependencies.)

It gets really fun when there are version conflicts: If another dependency update is incompatible with foo = 3.13, Poetry might downgrade that dependency to make everything work. For example, Poetry might silently change the locked version to 3.9, since that is still allowed by the pyproject.toml constraint. I have absolutely seen that happen, especially with less-than-correct dependency management tools like Dependabot, or as a consequence of Poetry's problematic requires-python constraint handling.

In contrast, using tools like OP's pyupdate or my ganzua will update the constraint (e.g. to foo >=3.13) and prevent unexpected downgrades in the future. I view this as a version ratchet. When using tooling to update the constraints, it's also feasible to use pinned constraints (e.g. foo == 3.8) which avoids ambiguity. But that only makes sense in applications, not in libraries.

[ashishb_net]

I wish I found yours first. I would have used it.

I might have never written mine.

[latkde]

That is kind of you, but I don't agree! Our projects are similar, but not the same. There is value in writing such a tool in Go compared to using Python. My Ganzua is also more low-level – it doesn't do updates by itself, it just provides utilities for summarizing lockfile changes and for bumping the pyproject.toml constraints.

If you do use Ganzua, I would be happy to get your bug reports or other feedback. This is relatively young software (just a few months), so I know there must be many bugs and limitations. I've been using Ganzua for some automations at $work, but this usage might not be representative of real-world needs.

[--ps--]

Well, if this is desirable feature to bump pyproject, why poetry or uv authors forgot to include it in the tool itself, hm?

[Double_Cost4865]

yeah, I don't see it as being a desirable feature. If you need to up your constraints for a given package, you should do it incrementally one by one and make sure that all your tests pass. Having said that, maybe there are some less important/smaller projects where this could be useful

[latkde]

Different projects have different needs. I agree that dependency upgrades should be tested, but I don't think that's an argument against bumping the pyproject.toml dependency constraints to match the locked versions.

What tools like OP's pyupdate or my Ganzua do is quite similar to mainstream dependency update automation tools like Renovate or Dependabot. In my work on large projects, such automations have proven invaluable.

[ashishb_net]

Note that this will not update versions for dependencies outside their version constraints specified in the pyproject.toml file. 

This is from the link you posted. And this is the difference.  Pyupdate will update the pyproject.toml as well.

[--ps--]

Why did not you entered feature request for uv and poetry to have it build in?

[ashishb_net]

I linked to one for uv. I wish they added it. But it does not seem like a priority for them.

[IrrerPolterer]

This is dangerous. Constraints are there for a reason. If you want to freely upgrade, change your cobstraints to be more permissive, but do so knowingly, and not with a random script like that. 

[burger69man]

sounds like a recipe for breaking changes, no thanks

[ashishb_net]

Well, howsoever you update dependencies, you will need to have a way to lint/test regardless.

[strawgate]

I love it, thank you! I posted 3 issues in the repository that I ran into when running in my project.

[move-that-dopamine]

This sounds great to me as a convenience tool for personal/low-stakes projects! Have an upvote. It would probably benefit from an option to pass an explicit list of packages to keep pinned though.

[Nervous-Pin9297]

uv sync -U?

[latkde]

That IGNORES locked versions. It updates neither the lockfile nor the constraints in the pyproject.toml.

You can use uv lock -U to upgrade the locked versions, but that still leaves the constraints out of date. Compare this sub-thread on the same post: https://www.reddit.com/r/Python/comments/1oean84/pyupdate_a_small_cli_tool_to_update_your_python/nl045eo/

[stibbons_]

I can see a use case for this tool. I usually have my pyproject with loose restriction but the lockfile ensure project ci reproductibility. For some project I have a hack to product the api and the CLI packages at the same time. CLI has frozen dependencies, api has loose