Update the lock file without upgrading dependencies

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Please provide a way to update the lock file without upgrading dependencies.

After adding a [tool.poetry.extras] section to pyproject.toml, Poetry displays the following warning, for example on install:

Warning: The lock file is not up to date with the latest changes in pyproject.toml. You may be getting outdated dependencies. Run update to update them.

That’s fine, but if I run poetry update it upgrades my dependencies, which is not what I want at this time. If I run poetry lock instead, it still upgrades dependencies. Am I missing something?

Here are the relevant files and the commit:

• pyproject.toml
• poetry.lock
• commit

Sorry for not providing a smaller reproducible example, it’s quite tricky to generate a poetry.lock file with outdated dependencies.

[PavlosMelissinos]

This functionality is much needed imo. A single package addition/update shouldn’t trigger a dependency graph resolution for all the dependencies of the project.

I’d rather poetry lock/poetry update be more conservative by default. If we want to keep the current functionality as well, even though I consider auto-updates to be a bad practice, there could be an additional flag like --refresh to force irrelevant dependencies to update as well if there’s a newer, compatible version.

[seansfkelley]

In https://github.com/python-poetry/poetry/issues/496#issuecomment-455913689 there is also outlined an alternate workaround: poetry add pathlib2 ; poetry remove pathlib2, where pathlib2 is any library you don’t already depend on and that has no dependents… like pathlib2. (Strictly speaking, it can be any library with a dependency tree disjoint from your project, but why drag in more stuff than you need?)

I use this workaround all the time. Updating metadata in the lockfiles, resolving merge conflicts, etc. All of these operations get me into a state where I want something like poetry lock --preserve (which doesn’t exist, but has a nice ring to it): re-locking, but keeping as many versions as possible where they currently are.