Switching from `pyrefly-typecheck-system` hook to `pyrefly-typecheck-specific-version` generates a bunch of new import errors

[rchen152]

In pytorch/helion#1143, I successfully got pyrefly running as a pre-commit hook using pyrefly-typecheck-system. When I attempted to follow a reviewer suggestion to switch to pyrefly-typecheck-specific-version, pyrefly then produced 300+ import errors. Here's the working pre-commit set-up:

-   repo: https://github.com/facebook/pyrefly-pre-commit
    rev: 0.0.1
    hooks:
      - id: pyrefly-typecheck-system
        name: Pyrefly (type checking)
        pass_filenames: false

and here's the one that produces boatloads of import errors:

-   repo: https://github.com/facebook/pyrefly-pre-commit
    rev: 0.0.1
    hooks:
      - id: pyrefly-typecheck-specific-version
        name: Pyrefly (type checking)
        pass_filenames: false
        additional_dependencies: ["pyrefly==0.42.0"]

[rchen152]

Hmm, looking at how the pre-commit hooks for mypy (https://github.com/pre-commit/mirrors-mypy) and pyright (RobertCraigie/pyright-python#324) work, it seems like I may just need to specify deps through additional_dependencies.

[rchen152]

I can make this work by reproducing helion's entire dependencies list in additional_dependencies, but that seems repetitive and non-ideal. Taking a closer look at other pre-commit hooks, it seems like a more typical way to do a "managed" install is for the pre-commit repository to bundle the tool it offers and mirror its version updates, so that version X.Y.Z of the pre-commit gets you version X.Y.Z of the tool. @lolpack have we considered doing this for pyrefly-pre-commit?

[oulgen]

pyright precommit also has the additonal_dependencies problem which is why helion used the system pyright (this breaks the "managed" abstraction). I think a good way to fix this would be for the precommit hook to read the pyproject file and pick the deps from there?

[rchen152]

Oh interesting! I didn't realize that pyright has the same problem.