Support pre-commit

[maresb]

It would be nice to make a pre-commit.com-compatible hook so that a Git repository can guarantee that the lockfile is up-to-date.

It would be nice to have a check vs fix feature, depending on whether or not conda-lock should update the working directory.

For speed we should probably default to just checking the hash. But there might be cases where it's desired to relock each time.

[Riezebos]

You can already define this hook yourself:

  - repo: local
    hooks:
      - id: conda-lock
        name: conda-lock
        entry: conda-lock lock -f environment.yml --check-input-hash
        language: python
        additional_dependencies: ["conda-lock==1.0.5"]
        always_run: true
        pass_filenames: false

I use version 1.0.5 because higher versions don't work with CI, as the full path to the environemnt file is stored in the lock file.

[maresb]

Thanks a lot for sharing this example! I had not yet gotten this far.

I do believe that storing the full path is a bug. Paths should be relative to the repo root.

Not sure if it helps in this case but you should be able to force the classical behavior in newer versions with -k explicit.

[Riezebos]

I agree, but it looks like this will be fixed in one of the next versions :)
See: #229

[maresb]

Ah yes, thanks for pointing this out. Looks like it's waiting on #204 which is stuck in review. I hope it gets merged soon.

[tomrutter]

I think it would still be good to support pre-commit directly. For example, the entries suggested above would create a local venv containing your local package and conda-lock. This is a little wasteful and would not work if your package has a dependency conflict with conda-lock. The only change would be to add a .pre-commit-hooks.yaml file to the root of the repo. I'd be happy to submit a PR if there is appetite for this.

[maresb]

@tomrutter, that would be excellent!

BTW I believe that the pre-commit venv would not install the project, so there should be no potential for conflicts.

[tomrutter]

You're right! So not such a big deal, but will get on it anyway!

[ctcjab]

Started using a solution based on the comment above, but eventually ran into a subtle and hard-to-debug issue, which I just reported in #743.

To summarize, when conda-lock is installed by pre-commit (in a private, disposable environment), it does not pick up the global conda config that the user's own, global conda-lock installation picks up from conda's base environment, resulting in failures to solve / generate lockfiles.

One workaround is to use pre-commit's language: system and require users to Bring Their Own conda-lock installation, but implicit global dependencies like this are bad for things like reproducible environments across different development hosts, CI, etc., so ideally #743 would be fixed instead.

Wanted to mention this here in case it could help save time for anyone else who hits this issue.