option to fail if `poetry.lock` doesn't match `pyproject.toml`

• 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.

steps

1: add dependencies and run poetry update 2: change dependencies and run poetry install

expected

The command fails as you will install dependencies that are not reflecting the project configuration

actual

All you get is a warning

Feature Request

currently when you run poetry install with an outdated lock file, you get this warning:

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.

it would be nice if there was an option to make this an error instead of a warning. in my case i want the CI to fail if poetry.lock is outdated.

the warning can be easily missed when running in CI

[DetachHead]

In my opinion, this feature would be counterintuitive and it wouldn’t add much value.

I disagree. If I change/add a dependency in pyproject.toml and forget to run poetry update, I’ll experience unexpected behaviour where the cause won’t be immediately obvious. Other similar tools such as npm and gradle fail when the lock file is outdated

I think adding a command line option to remove the assertions made by a lock file would be confusing

I’m not asking for an option to remove the lock file’s assertions, only an option to fail if pyproject.toml contradicts those assertions

[glencairn]

If the version of a dependency in the lock file does not satisfy the constraints specified in the pyproject.toml file, you will get an error when running poetry install (the error description is pretty bad though). Just because a locked dependency is out of date does not mean that it violates your project’s constraints.

i just ran poetry install where the pyproject.toml has new dependencies in it that are not present at all in the poetry.lock file. i would expect an error message when poetry install isn’t going to install all of the dependencies specified in pyproject.toml because as you said it does not satisfy the constraints specified in the pyproject.toml file

i just tried poetry lock --check and it picks up this issue

Ah, I see. My example was only addressing the case where the version of an existing dependency is changed manually. I had not considered the case where a new dependency is added manually and not via poetry add. But I agree with you, poetry should be able to identify when a dependency specified in the pyproject.toml file doesn’t exist in a lock file when running poetry install.

I am interested in the decision to add dependencies manually vs using poetry add. It’s definitely a valid workflow but could you elaborate on why you prefer that workflow?

---

@KotlinIsland agreed 😆