I think uv lock should suffice for pre-commit as added in #13. What benefit is there to doing uv sync? The virtual environment should not be committed.

Definitely don't want to be committing the virtual environment. This would be running post-merge rather than pre-commit.

If you are working on a codebase with a frequently changing lockfile, then often the main branch will be merged back into a dev branch, updating the lockfile, but rendering your environment out of date. Yes, the lockfile might automatically get updated every commit on the dev branch with uv lock, but this doesn't do anything to ensure your environment is up-to-date after a merge from a different branch.

One way to deal with this is to display a warning when the lockfile is out-of-sync with the current environment, but if it's happening frequently, users might just want to automatically run uv sync after any merge rather than having to remember to do it themselves. It might also make it easier to deal with merge conflicts in the lockfile (?).

This is exactly what I was looking for 😄

My projects are currently based on Poetry and I have these hooks set-up, and they are just great to keep project in sync, especially since dependabot updates my dependencies on a daily basis.

post-checkout would also be a good stage to run this after

@nathanjmcdougall
@zanieb

Correct me if wrong but I assume there is no perfect solution for this.
According to pre-commit documentation post-merge hooks always run, regardless of which files have changed.

post-merge hooks do not operate on files so they must be set as always_run: true or they will always be skipped.

Therefore, adding a post-merge hook to check if only uv.lock or pyproject.toml has changed and then running uv sync is not possible.

Basically, uv sync will always run after each merge, regardless of which files were modified.

With this consideration, a sample hook will look like this:

      - id: uv-sync
      name: uv-sync
      description: "Automatically run 'uv sync' after merge or pull"
      entry: uv sync --locked
      language: python
      args: []
      stages: [post-merge]
      always_run: true
      pass_filenames: false
      additional_dependencies: []
      minimum_pre_commit_version: "2.9.2"

@nathanjmcdougall
@zanieb

Correct me if wrong but I assume there is no perfect solution for this.
According to pre-commit documentation post-merge hooks always run, regardless of which files have changed.

post-merge hooks do not operate on files so they must be set as always_run: true or they will always be skipped.

Therefore, adding a post-merge hook to check if only uv.lock or pyproject.toml has changed and then running uv sync is not possible.

Basically, uv sync will always run after each merge, regardless of which files were modified.

With this consideration, a sample hook will look like this:

      - id: uv-sync
      name: uv-sync
      description: "Automatically run 'uv sync' after merge or pull"
      entry: uv sync --locked
      language: python
      args: []
      stages: [post-merge]
      always_run: true
      pass_filenames: false
      additional_dependencies: []
      minimum_pre_commit_version: "2.9.2"

You are right, however uv being fast, the overhead would be acceptable for most of us.

Besides, I remember git hooks are providing base and head commits, I don't know if pre-commit passes them but we could check if pyproject.toml or uv.lock has changed between both to detect if sync is required.

I am looking after this feature too.

PDM provides such a hook, pdm-sync, it runs on post-checkout, post-merge and post-rewrite. I think it runs every time, but as pointed out by @lachaib uv is so fast this is acceptable. Moreover, it is an opt-in behaviour.

In the meantime, I am using an alternative solution with direnv. I set it up to watch for changes in uv.lock and to run uv sync, something along those lines:

# Rerun .envrc whenever uv.lock changes
watch_file uv.lock
uv sync --quiet
# Bonus: automatically activate the virtual env
direnv_load uv run direnv dump