+1 for this feature. Our project is pretty big where many folks, with various skills, contribute and when dependencies move in unexpected ways, it creates lots of waves. It's better to be explicit in such situations and do exactly what the user is requesting.

@seansfkelley Hi! Does it mean that by using "update command or some kind of --update flag to lock" I'll be able to change current versions of packages in my .lock file?

If this is implemented, please also make poetry add not try to automatically update unrelated dependencies.

@nyuszika7h , poetry add already behaves like that no? I tested like this:

Current SQLAlchemy's version is 1.4.36.

1. Create a pyproject.toml with 1.4.35 and generate a lock file.
2. Update pyproject.toml with ^1.4.0.
3. Now do poetry add hello-world.

This doesn't update the SQLAlchemy version and installs all the packages as well.

However, in step 3, if you manually add hello-world to pyproject.toml and do a poetry install, it refuses to do so stating that it is not in the lock file (resolution error). Now, we need to poetry lock again - and that is where the problem happens. So, I think it makes sense for both APIs to behave the same way; which is what this requirement is about.

If the above understanding is correct, we will never get into this issue if we use add or remove, but only via manual update -- and that too only because of the need to lock explicitly.

Actually, what would be the difference between:

• poetry lock --update: generate the lock file, updating the dependencies
• poetry update: update the dependencies, generating the lock file

No one of the two will change the content of pyproject.toml, and then they both generate a lock file compliant with it.

To me, the two commands are doing the same operation, but maybe I'm just not able to spot the difference.

If this is actually true, it would be confusing to have two different commands performing the exact same operation, so I'd rather propose to make poetry lock always behaving in the --no-update mode, and nothing else. To update, there is a dedicated command.

@alecandido , Yes, I had this doubt as well. I think poetry needs to just provide one way of doing things unless absolutely avoidable. poetry lock should do the behaviour requested here; poetry update should do the update + lock.

Not my words ;)

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

                                          import this, or The Zen of Python (PEP 20)

What is the status of this? It's still causing confusion a year later :D

I think the status is that just doing it would be a breaking change in the user interface and we'll probably don't want to do a major version bump just for this. (This is just my personal opinion.)

Some further thoughts:

We might need a better name for the new option than --update because what poetry lock currently does, is not updating dependencies in an existing lockfile (that's poetry update --lock). poetry lock ignores an existing lockfile completely and creates a new lockfile from scratch. Often poetry lock and poetry update --lock lead to the same result, but these two commands are not the same. Proposals for a better name than --update are welcome.

I assume we could speed up the progress, if we find a solution without an immediate breaking change (deprecation first) although that would mean more effort - at least if someone is motivated enough to work on such a solution. The only option for a soft change that I can think of is:

• keep --no-update
• add a new option which corresponds to the current behavior of poetry lock
• print a warning that says that the behavior will change when poetry lock is called without any of the two options

After some time with this warning we could switch the behavior of poetry lock.

Not sure if that's a good approach. 🤷

@radoering may you provide a couple of use cases to understand the difference?
One in which it should be preferable to use poetry update --lock, and another one in which instead it's better to use poetry lock.

This would be a valuable piece of information also in the docs.

Moreover, the --lock option in poetry update is also possibly a misnomer, since it doesn't change at all what happens to the lockfile (according to the docs), but only to the environment (it could be renamed --keep-env, or something like that).

With poetry update <package> you can update a certain dependency and keep others. Apart from that (if you don't pass any packages), I don't know if there really are use cases or if the difference is only technically.

Personally, I don't use poetry update (without passing a dependency) at all. Not sure, if that's still true, but in the past poetry lock was just more stable and robust than poetry update --lock. If you don't have to take an existing lockfile into consideration there is one less uncertainty. If you run poetry lock twice, you will get the same result (if no dependency released a new version in the meantime). At least in the past, we had cases where subsequent calls of poetry update --lock toggled between two states (because the latest versions of two dependencies excluded each other). That might not be an issue anymore, but I hope it's clear what I'm getting at.

Moreover, the --lock option in poetry update is also possibly a misnomer, since it doesn't change at all what happens to the lockfile (according to the docs), but only to the environment (it could be renamed --keep-env, or something like that).

Or poetry update --no-install? On the other side --lock is also used for poetry add and poetry remove and at least for the latter --no-install makes no sense. --keep-env would be more correct but I'm not sure I like it. --lock-only might also make sense but it's longer than --lock... Not sure about that. Naming is always difficult, especially for something like a command line option that is typed often and probably shouldn't be too long...

Personally, I don't use poetry update (without passing a dependency) at all. Not sure, if that's still true, but in the past poetry lock was just more stable and robust than poetry update --lock.

Ok, I see. But then there is arguably a strict sorting between poetry update (no args) and poetry lock.
I'm not strongly opinionated about the best course of action, but I believe that the present state it's not great: either the difference is understandable from the average user and documented, or only one of the two options should survive.

E.g. keeping poetry update <package> and poetry lock/poetry lock --update might be a sensible option.

Naming is always difficult

About this I can only agree :)