`poetry lock --no-update` does not always update generated comment in lockfile

[lg-kialo]

• Poetry version: 1.6.1

• Python version: 3.11.4

• OS version and name: Ubuntu 22.04

• pyproject.toml: Not relevant

• I am on the latest stable Poetry version, installed using a recommended method.

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

• I have consulted the FAQ and blog for any relevant entries or release notes.

• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

When generating the lockfile, Poetry stores its own version in the @generated comment at the top of the lockfile. This was added in #7339.

The issue is that this comment is updated by Poetry only when there are changes to the lockfile other than the version used to generate it. That is: if I run poetry lock --no-update with Poetry 1.6.1, then change manually the comment at the top of the lockfile to say version 1.5.1, then run again poetry lock --no-update, the comment won't be updated, it will still say Poetry 1.5.1.
That's because in this function, do_write is False if all the metadata is equal but the @generated comment is different. In turn, that's due to TOMLKit effectively ignoring (top-level?) comments when comparing documents.
If, for instance, I manually alter the content-hash of the lockfile to something different and then run poetry lock --no-update, the lockfile will be refreshed and the comment at the top updated to say Poetry 1.6.1..

My expectation would be that the comment at the top of the lockfile would still be refreshed even if it's the only change, when running poetry lock --no-update.

If there's an agreement in favour of this change I'd be happy to try putting a PR together.

[radoering]

Not sure about that. poetry lock --no-update just does not write the lockfile if not necessary. Thus, the @generated comment is still correct.

[abn]

I do not think this should be changed as this may cause unwanted side-effects if multiple people on the team are on different versions of Poetry even different patch levels. It will get annoying for larger teams.

We should either drop the version altogether or do nothing else.

[radoering]

Personally, I think it's extremely helpful to have the version in the comment (to know the version a lockfile has been generated with) for debugging reasons or to tell people that they should update Poetry. 😉

Thus, I think we can close this as not planned.

[github-actions]

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