(🎁) upgrade warning about inconsistent lock file to an error

[KotlinIsland]

Pull Request Check List

• Resolves: option to fail if poetry.lock doesn't match pyproject.toml #5003

This is an extremely common issue that I see people running into all the time, there is a warning at the top of the output about the invalid state of the project, but it is instantly hidden by a wall of other output.

Finally poetry says that the version doesn't exist. Confusingly, poetry is only referring to versions in the lock file that don't exist.

• [🚀] Added tests for changed code.
• [🚀] Updated documentation for changed code.

[ilyagr]

Will this allow running Poetry 1.7 (or 1.8) on a lockfile generated by Poetry 1.6? Currently, that generates a warning since the lockfile doesn't match exactly what Poetry 1.7 would generate; I'd hate for that to become an error.

BTW, I agree that erroring out when the lockfile is incompatible with pyproject.toml is a good idea.

[radoering]

that generates a warning since the lockfile doesn't match exactly what Poetry 1.7 would generate

It does not generate this warning, does it? Actually, I'm not aware that it generates a warning at all. The last update of the lockfile version was in Poetry 1.3.

[ilyagr]

Actually, I'm not aware that it generates a warning at all.

Hmm... I was sure I saw it, but I couldn't actually reproduce it. I will let you know if I find it again.

For reference, here is what the diff looks like between a lockfile generated by Poetry 1.3 and Poetry 1.7.1. The differences are slight, but this is what I thought (seemingly incorrectly?) Poetry was complaining about.

diff --git a/poetry.lock b/poetry.lock
index e933ba2ee6...955471c81b 100644
--- a/poetry.lock
+++ b/poetry.lock
@@ -1,10 +1,9 @@
-# This file is automatically @generated by Poetry and should not be changed by hand.
+# This file is automatically @generated by Poetry 1.7.1 and should not be changed by hand.

 [[package]]
 name = "babel"
 version = "2.14.0"
 description = "Internationalization utilities"
-category = "dev"
 optional = false
 python-versions = ">=3.7"
 files = [

(there are then many repeats of the -category = "dev" line).

[radoering]

category is not written anymore because it has not been read even longer. This should not produce any warning since we decided not to bump the lockfile version. See #7637 for details.

The only risk in this PR is that users edited the pyproject.toml, did not lock because they knew that their change did not affect the lockfile except for the hash and deliberately ignored this warning. This workflow will not work anymore after this change. I suppose we can/should take that risk to improve the feedback for the majority of users.

[ilyagr]

The only risk in this PR is that users edited the pyproject.toml, did not lock because they knew that their change did not affect the lockfile except for the hash and deliberately ignored this warning.

I did not realize that poetry.lock contained a hash of the pyproject.toml, so changing a comment in the latter invalidates the former. This might be the warning that confused me.

I don't think this behavior is inherently problematic, but see below for a suggestion about wording.

I suppose we can/should take that risk to improve the feedback for the majority of users.

This seems like a reasonable tradeoff.

One way to make it friendlier is to mention this possibility in the error message, saying something "pyproject.toml changed since poetry.lock was generated". When it says that "poetry.lock is not consistent with pyproject.toml", I assumed it checked that the versions of packages in poetry.lock don't satisfy the version specifiers in pyproject.toml.

P.S. I do appreciate that the same lockfile can be used with a wide variety of versions of poetry. It's nice when people who do sudo apt install poetry and get Poetry 1.3 can work with my project.

[radoering]

I did not realize that poetry.lock contained a hash of the pyproject.toml, so changing a comment in the latter invalidates the former. This might be the warning that confused me.

It's not a hash of the entire pyproject.toml. Only fields that are relevant for locking are considered.

"pyproject.toml changed since poetry.lock was generated"

Maybe we should say "relevant fields of pyproject.toml changed ..."?

[KotlinIsland]

P.S. I do appreciate that the same lockfile can be used with a wide variety of versions of poetry. It's nice when people who do sudo apt install poetry and get Poetry 1.3 can work with my project.

If I ever saw anyone that had been tricked into using apt for installing poetry, I would direct them towards the actual install instructions, or pyprojectx

Also, it's sudo apt install python3-poetry, which will be 1.1.12 if you're on the LTS.

[ilyagr]

Maybe we should say "relevant fields of pyproject.toml changed ..."?

Maybe "Dependencies changed in pyproject.toml since poetry.lock was generated"?

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.