Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

I'd like to be able to validate that a lock file has been created from the current source specifiction's contents. So for example, if someone changes environment.yml and opens a PR, my CI could very quickly catch that the lockfile wasn't updated by re-calculating a hash and comparing it to content_hash in the lockfile.

conda-lock lock --check-input-hash is very close to what I want to do, with the downside that instead of failing immediately if the hash validation fails, it will solve the environment and update the lockfile. What about a --check-input-hash-without-solve or similar flag for this behavior?

Why is this needed?

This helps projects automatically catch and quickly prompt (by e.g. failing CI job or bot comment) contributors who have forgotten to lock the environment after changing it. This repo2docker-based project, for example, expects users to manually update their lockfile or use /condalock in a PR comment to trigger a bot to update the lock file, but they have to remember to do that!

Detecting that environment.yml has changed isn't enough. Sure, if conda-lock.yml also hasn't changed, we can be relatively assured that the user forgot to update the lock-file. But if conda-lock.yml has changed, how do we know the version of environment.yml that's being committed is the same content that generated conda-lock.yml? The contributor could have updated environment.yml, locked it, then changed environment.yml again before committing.

Using pre-commit with --check-input-hash is a great solution for people like me who are going to clone the repo and work on their local machines, but changing environment.yml in the GitHub interface is also a common workflow for some projects/users.

What should happen?

On running some command like conda-lock ensure-sources or conda-lock lock --check-input-hash-without-solve:

1. Calculate a new content_hash from sources in conda-lock.yml
2. Does it match content_hash in conda-lock.yml?
3. If yes, exit 0, if no exit non-zero

No solve or write to a file should occur at any time.

This should also work for "explicit" lockfiles which contain an input_hash in the header.

Additional Context

I apologize if this has been asked already! Tried to find it and came up empty.