Keep lock --check, instead of deprecating it? IMO "only check lockfile" is a common use-case.

[Kache]

I tried lock --check's replacement, check --lock. My (paraphrased) Dockerfile with lock --check is like:

1. install poetry
2. copy pyproject.toml and poetry.lock
3. poetry lock --check && poetry install
4. copy src files

So that daily development changes to src files do not require a poetry install. However, using check --lock means having to:

1. install poetry
2. copy pyproject.toml, poetry.lock, and README.md
3. poetry check --lock && poetry install
4. copy src files

Because it seems check intends to "run a single command in CI and get all validation performed", and it turns out "all validation" means failing if I don't copy in my README.md file into the Docker container.

I'd prefer not to:

• copy in the unnecessary README.md file into my container
• have to poetry install after changing README.md

Unless there's some alternative solution, please keep lock --check as an "only check lockfile consistency" feature.

[radoering]

Option A: Do not define a readme in your pyproject.toml if you do not care about it.

Option B: Just create an empty readme file in your docker container if you do not want to copy your original readme.

[Kache]

Those are good workarounds, but my point is the common use case of "I only want to do lockfile check for caching venv layer before everything else" for docker containers, which doesn't match check's semantics of "verify everything".

For example, future validations added to check would also need such workarounds to satisfy that common use-case.