Suggestion: new command to bump versions of dependencies in pyproject.toml

I have searched the issues of this repo and believe that this is not a duplicate.

Issue

It would be awesome if Poetry had a command (let's call it upgrade) that bumped the version constraints of dependencies in pyproject.toml (as opposed to update, which afaict updates the lock file to the newest version within the constraint specified in pyproject.toml).

Some examples for how this command could behave:

poetry upgrade django: Upgrade Django to the newest version that still works with other dependencies; equivalent to poetry remove django; poetry add django.
poetry upgrade django djangorestframework: As above, but with more than one package at a time.
poetry upgrade django=^2.1: Set the version of django to ^2.1, equivalent to poetry remove django; poetry add django=^2.1.
poetry upgrade: Upgrade every dependency to the newest possible version. Equivalent to deleting the entire [tool.poetry.dependencies] section of pyproject.toml and running poetry add with a list of the names (but not versions) of every package previously in the list. (This one would be good for cookiecutter templates for projects, to make it easy to start a new project with the latest versions of everything.)

Currently, when I want to bump the version of something, I'm either running poetry remove ...; poetry add ... which moves the package to the bottom of the list in pyproject.toml, and results in uninstalling a bunch of dependencies which sometimes just get reinstalled again at the same version; or I'm manually editing pyproject.toml which means I have to look up the latest version manually, and I can't use Poetry's version resolution when I want to upgrade more than one package at a time.

It's a bit dangerous to upgrade everything to the last version. you might introduce many bugs doing this, without knowing where it comes from.

Anyway I also do this 😆

upgrade is very confusing with the update command.
We could have acommand per package and for all.

Maybe --reset-dependency package_name or/and --reset-dependency-all would be less confusing.
or : --find-latest, --upgrade-to-latest,--force-latest

I agree; I only used ‘upgrade’ because I couldn’t think of something better :) It could also be added to ‘poetry add’ (either with or without a flag); currently that command just errors if you try to use it on a package that’s already in your dependencies.

…

On Tue, 2 Oct 2018 at 18:52, jgirardet ***@***.***> wrote: It's a bit dangerous to upgrade everything to the last version. you might introduce many bugs doing this, without knowing where it comes from. Anyway I also do this 😆 upgrade is very confusing with the update command. We could have acommand per package and for all. Maybe --reset-dependency package_name or/and --reset-dependency-all would be less confusing. or : --find-latest, --upgrade-to-latest,--force-latest — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#461 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAc7aLMzza48JHvRq92e6REbrmtJqsAzks5ugzAzgaJpZM4XDWit> .

@sdispater

I'll put a PR if @sdispater accepts the idea

The JS package managers make add do an upgrade of the version range, and that makes sense to me.

@miracle2k

The JS package managers make add do an upgrade of the version range, and that makes sense to me.

@miracle2k
This is one of the many things that npm and yarn get right.

For example, if you yarn add abc, yarn might install abc version 2.2.1, and it will save this dep in package.json as "abc": "^2.2.1",.

In other words, when adding a package it uses the same caret prefix that poetry uses, and which permits subsequent updates to any version 2.X. I think this is a sensible default.

If you poetry add uWSGI, for example, it installs 2.0.18, but it saves this in pyproject.toml as uWSGI = "^2.0"... Why not save this as uWSGI = "^2.0.18"? This would behave the same under subsequent invocations of poetry update uWSGI, but it gives users immediate information about which version of the package is installed (2.0.18).

@jgirardet
I think a sensible implementation would involve a simple post-install step for both poetry add and poetry update. After running either of these commands, poetry could get the actual installed version of all dependencies and dev-dependencies, and update their versions in pyproject.toml, keeping the same caret or tilde prefix that the dep currently has.

In other words, if you have uWSGI = "^2.0.17" installed and you run poetry update uWSGI, it installs 2.0.18 and changes the line in pyproject.toml to uWSGI = "^2.0.18".

For wildcard (*) and gt, gte, lt and lte deps this behavior doesn't make sense, but caret and tilde requirements are by far the most commonly used.

If you make a script like this one at the root of the repo, make it executable, and run it with python3.7, it'll print the contents of pyproject.toml to the console after all ^ and ~ deps have been updated to their actual installed versions.

#!/usr/local/bin/python3.7
from typing import cast, Dict
import toml
import subprocess


def update_deps(name: str, version: str, t: Dict) -> Dict:
    def update(deps: Dict) -> None:
        for key in deps:
            v = deps[key]
            if type(v) is str and name.lower() == key.lower() and v[0] in ("~", "^"):
                deps[key] = f"{v[0]}{version}"

    update(t['tool']['poetry']['dependencies'])
    update(t['tool']['poetry']['dev-dependencies'])

    return t


with open('./pyproject.toml', 'r') as f:
    t = cast(Dict, toml.loads(f.read()))
    output = subprocess.run(["poetry", "show"], capture_output=True)
    lines = cast(str, output.stdout.decode()).split('\n')

    for line in filter(lambda l: bool(l), lines):
        name, version, *_ = line.split()
        t = update_deps(name, version, t)

    print(toml.dumps(t))

This is a goofy implementation that uses subprocess to call poetry show. It's just a proof of concept.

I think something like this happen after add and update are run, to update deps in pyproject.toml to their actual current versions.

If npm and yarn already do it in the add command, maybe keeping it consistent with what users already now would be better?

I also think that upgrade could be more confusing than useful. From other package managers, I would expect update/upgrade to just modify the lock file but not touch the dependencies definition file (tool in our case).

If you use the latest beta release of the 1.0.0 version, you can upgrade your dependencies by using a specific constraint or the special latest constraint.

poetry add pendulum@latest
poetry add pendulum@^2.0.5

See #1221 for more information.

@sdispater

@sdispater But what about updating all dependencies at once?

Can we reopen this?

It is a bit tedious to go over all of them manually.

@sdispater

While the command mentioned by @sdispater is nice, it doesn't go all the way to solving the problem talked about in this issue since you still have to go one by one and check each package.

I thinks the request about an upgrade command to update all dependencies to the latest available version is valid. So I reopen it.

This feature is open 6 years now, and people are still commenting. It's something that clearly the community needs.

Right now we use dependabot and renovate as an external weekly service that opens PR automatically with related updates.

@sdispater

@sdispater any updates on this?

How is this not a feature.

The issue is that poetry add removes the existing line i.e if source is defined then they are remove (if not specified with the add function).
Can't we really just update the package version constraint in the toml-file automatically?

This. Why does poetry not do this. If someone can help point me to an article that shows how to code poetry adn gives me a high level overview of where in the package would be acceptable to structure such an algo i would be happy to give it a go.

Thinking something like this (though im sure when i start it would be much more complex):

For all project.toml packages get average monthly downloads && versions+date published (use this to preference which libs are most likely to be changed in case where multiple conflicts)
For Each package get dep tree
Analyze dep tree for conflicts
Handle package renames + data external to pypi.
Where conflict, take lowest versions and downgrade conflicting packages , re-analyze dep tree + conflicts
repeat.

Does it need to be so complicated?
The 7 year old proposal is elegant: "remove" the dependency (without breaking everything else), then add it again, poetry resolves the best version automatically.

Does it need to be so complicated? The 7 year old proposal is elegant: "remove" the dependency (without breaking everything else), then add it again, poetry resolves the best version automatically.

poetry remove doesn't just remove the package from the environment; it deletes the corresponding dependency line entirely from your pyproject.toml. This erases the specific constraints (^1.0, ~=2.1, etc.), extras, source details, or markers you might have carefully configured for that dependency.

poetry add doesn't restore any of the specific configurations (extras, markers, original constraint type or version range) that were deleted; it typically adds the package back using a default caret (^) constraint based on the latest compatible version.

Could a remove/add script still be used? Yes, theoretically, but only under very strict assumptions and limitations. For example, the script would need to intelligently avoid processing any dependencies with complex configurations (like those using extras, markers, Git/path sources, or {...} table definitions).

That's exactly why I put remove in quotes and why this would be a new feature request which poetry doesn't support since 7 years 😅
For the easiest case possible (remove a dependency line containing only a version constraint without subdependencies) the naive workaround should already work.
So the trick would be to gather all correlating configurations from this "single" dependency line (constraints, extras, Git/source details, markers, table definitions) and restore them before readding them with a bumped version constraint.

Just feels odd that bumping only the version constraint and leaving everything else as it is and just running poetry update urllib3 internally wouldn't be easier... 🤔

dependencies = [
    "urllib3~=1.26.0",
]

dependencies = [
    "urllib3~=2.4.0",
]

And this feature request isn't even about updating the lockfile, only the version constraint in pyproject.toml.

That's exactly why I put remove in quotes and why this would be a new feature request which poetry doesn't support since 7 years 😅 For the easiest case possible (remove a dependency line containing only a version constraint without subdependencies) the naive workaround should already work. So the trick would be to gather all correlating configurations from this "single" dependency line (constraints, extras, Git/source details, markers, table definitions) and restore them before readding them with a bumped version constraint.

Just feels odd that bumping only the version constraint and leaving everything else as it is and just running poetry update urllib3 internally wouldn't be easier... 🤔

dependencies = [
"urllib3~=1.26.0",
]
dependencies = [
"urllib3~=2.4.0",
]
And this feature request isn't even about updating the lockfile, only the version constraint in pyproject.toml.

Sounds good!

I've been using this, and it has served me well so far:

grep -oP '^\s*"\K[^"\s]+(?=\s*\()' pyproject.toml | xargs -I{} poetry add {}@latest

Hi,

what is a reason it is still not implemented? Is it a philosophical issue or there is not enough people to work?

what is a reason it is still not implemented?

I believe because people use uv lock --upgrade instead.

@Natim

@Natim you may be confused with astral-sh/uv#6794

Yes, it implements this feature, and I believe people who need it have already moved to it. That's the reason Poetry doesn't feel more pressure to implement this urgently anymore.

Navigation Menu

Repository navigation

Suggestion: new command to bump versions of dependencies in `pyproject.toml` #461

Issue

41 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggestion: new command to bump versions of dependencies in pyproject.toml #461

Description

Issue

Activity

jgirardet commented on Oct 2, 2018

daisylb commented on Oct 2, 2018

jgirardet commented on Oct 2, 2018

miracle2k commented on Oct 18, 2018

kylebebak commented on Jul 9, 2019

kylebebak commented on Jul 10, 2019

jmfederico commented on Aug 8, 2019

sdispater commented on Oct 30, 2019

max-wittig commented on Nov 2, 2019

Natim commented on Dec 16, 2019

dmwyatt commented on Jun 9, 2020

finswimmer commented on Jun 10, 2020

41 remaining items

petros94 commented on Oct 22, 2024

Natim commented on Oct 22, 2024

SanitizedMemory commented on Feb 12, 2025

toby-j commented on Feb 19, 2025

HenningDinero commented on Feb 20, 2025

davewd commented on May 4, 2025

reneleonhardt commented on May 5, 2025

Elijas commented on May 5, 2025

reneleonhardt commented on May 5, 2025

Elijas commented on May 7, 2025

codespearhead commented on Jul 7, 2025

wieczyk commented on Jul 7, 2026

Natim commented on Jul 7, 2026

dimbleby commented on Jul 7, 2026

Natim commented on Jul 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Suggestion: new command to bump versions of dependencies in `pyproject.toml` #461