This is more a consequence of the fact that loading the config (basically Poetry()/the old Factory.create_poetry()) runs the validation as it creates a full application instance.

I'm saying that most commands will validate pyproject.toml since we don't read it lazily to populate the internal representation, but I'm not sure there's a good way to communicate that. This is correct, just not exhaustive.

My motivation is to be able to point co-workers at a canonical, single command to validate Poetry config and lockfile freshness. I think ideally I agree with Sebastian's comment from last year that this would have been implemented as poetry check --lock:

• #453 Add command to check poetry.lock freshness #1954 (comment)

In terms of the status quo, should developers not rely on the side effect that poetry lock --check also invokes the internals of poetry check? Would the recommendation in CI be running both:

poetry check
poetry lock --check

I'd like be sure I'm not recommending relying on some internal behavior of Poetry.

I wouldn't mind deprecating lock --check in favor of check --lock and moving all the code there/making the deprecated usage simply an alias. I think that would be the most obvious and clean solution for Poetry going forward.

Closing in favor of

• Replace poetry lock --check with poetry check --lock #6756

In case anyone comes across this, I learned today that poetry lock --check does not in fact validate everything that poetry check does (i.e. it is not a superset of validation). For example, Trove classifiers are validated in poetry check but not poetry lock --check.

So, to get the full amount of checking, a user currently needs to run two steps in CI:

poetry check
poetry lock --check

As mentioned above, this UX would be improved with:

• Replace poetry lock --check with poetry check --lock #6756

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.