Support synchronizing additional-dependencies

[lachaib]

Hi,

I have come across issue #29 so I know there's a workaround already proposed, however I'd like to give a fresher use case. The one of mypy.

Currently, I'm running mypy from local because it's the only way I can get the additional types in the version they are tested with.
However it's rather verbose and maybe error prone with regards to the ecosystem's evolution.

      - id: mypy
        name: mypy
        entry: uv run mypy
        language: python
        pass_filenames: true
        types_or: [python, pyi]

What I'd like is to use the proper hook mirrors-mypy to simplify the writing of my hook

   -   repo: https://github.com/pre-commit/mirrors-mypy
       rev: v2.1.0
       hooks:
         - id: mypy
           additional_dependencies:
             - types-redis==4.6.0.20241004
             - types-pyyaml==6.0.12.20260518

Using sync-with-uv to sync additional_dependencies would be a real win to ensure the pre-commit is inline with what a developer gets and what CI will return, without having to recode the types_or and other fancy things I need to get it to work from "local" repository.

If you can accept it as a valuable addition I'd be glad to work on it.

[tsvikas]

Thanks, the mypy framing helps, but I think it actually argues against adding this.

1. Syncing additional_dependencies is a different operation from what the tool does today. Right now it only bumps rev in place.
2. To be useful for mypy it would have to include all dependencies (not only the types-* stubs) which effectively reproduces your entire lockfile inside the pre-commit YAML, kept in sync on every uv.lock change.
3. To be useful for mypy it would have to also manage which entries exist, not just their versions, because mypy needs every dependency present to see its types. So the tool would have to add and remove entries as your pyproject changes

That's a lot of duplication and a much larger feature than the in-place version sync this tool is built around, so I'd rather not take it on. That said, if you see it working out differently, the best way to convince me is to build it, run it on a real project, check that the UX holds up, and present it here. I'll gladly take a look.

The use case is real though, and unfortunately I don't think there's a clean answer that sits between these two tools.
For the mypy case specifically I'd suggest one of: keeping the local hook you already have, running mypy in CI instead of pre-commit, or trying ty, which I believe can run without the project venv.

Appreciate the idea and offer to work on it!

[tsvikas]

Update: a new feature in sync-with-uv can help in this case

It shipped in #56, which adds opt-in syncing of dependency lines, using a pragma-comment.

The thing that unblocked it was making the sync opt-in per line - that keeps it the same in-place version sync the tool already does for rev, and skip the "own the whole additional_dependencies list" operation I was reluctant about.

For your mypy example it looks like this:

- repo: https://github.com/pre-commit/mirrors-mypy
  rev: v2.1.0
  hooks:
    - id: mypy
      additional_dependencies:
        - types-redis  # sync-with-uv
        - types-pyyaml  # sync-with-uv

On each run, every annotated line is pinned to the exact uv.lock version (a bare name gets an == pin added, an existing specifier is rewritten to ==), so the above becomes types-redis==<locked> and types-pyyaml==<locked>. Extras, environment markers, quoting, and the comment itself are preserved, and the package name is matched after PEP 503 normalization. Because the pragma is an explicit request, an annotated line whose package isn't in uv.lock is an error rather than a silent no-op.

Points 2 and 3 from my earlier reply still hold, though. I really do not recommend using this tool (or pre-commit) with mypy. The tool keeps the versions of the entries you list in step with uv.lock, but it won't enumerate the full dependency set for you, and it won't add or remove entries as your pyproject changes. So for the "mypy needs every dependency present to see its types" case, you're still responsible for choosing which lines exist.

Thanks for the suggestion - it's part of what made the shape of the feature click.