Avoid Cargo as a dependency for using deptry with pre-commit

[nathanjmcdougall]

Is your feature request related to a problem? Please describe.

As of v0.14.0, building deptry requires Cargo to be installed.
Since pre-commit builds the pre-commits locally, this means that using deptry with pre-commit requires Cargo.

Describe the solution you would like

I think the documentation could be updated to explain this fact.

An alternative way to use deptry with pre-commit would be to get it to run locally:

-   repo: local
    hooks:
    -   id: deptry
        name: deptry
        entry: deptry .
        additional_dependencies: [deptry==0.14.0]
        language: python
        always_run: true
        pass_filenames: false

Or perhaps using language: system and not including additional_dependencies explicitly.

Perhaps this could be suggested as a recommended workaround, in the documentation.

Additional context

See #590.

[mkniewallner]

Hey, sorry for that, indeed, we should probably do something similar to https://github.com/astral-sh/ruff-pre-commit and https://github.com/pre-commit/mirrors-mypy and store hooks in a separate repository, so that we can depend on wheels. We'll work on that soon, in the meantime the solution you suggest should work.

[mkniewallner]

Checking https://github.com/fpgmaas/deptry/blob/45b1e13926d37e725c0d328fb5ef5dece3d48139/.pre-commit-hooks.yaml, our current hook uses system, and assumes that users are in a virtual environment where deptry is installed as a dependency (for instance through Poetry, pip, etc.). This is also documented here. So most users using the current hook should not be affected.

But although not really related to this issue, IMO our current hook is probably not that helpful, as if we end up relying on system, we might as well let users configure the hook themselves (to for instance let them define poetry run deptry instead of just deptry and not have to activate their virtual environment).

Given that an option to define the mapping of packages to modules exists, I wonder if we could not have a pre-commit hook that runs in its own environment, and document that if users want to use that, this is supported, but they will need to manually define the mapping, as deptry won't be able to infer the mapping. And in the documentation, we could also show an example on how to configure the hook as a system one, if users want to benefit from pre-commit while having the auto-mapping. Any thoughts on that @fpgmaas?

[fpgmaas]

The main question I have with that solution is; why would a user choose to run the pre-commit hook in its own environment and define the mapping manually from scratch, rather than use the pre-commit hook as a system one and have deptry automate it for you?

[nathanjmcdougall]

For me, I haven't been successfully been able to use deptry as a pre-commit (git) hook when calling system. I get

'deptry' is not recognized as an internal or external command,
operable program or batch file.

Which implies the virtual environment is not being activated. But as far as I understand this is the intended behaviour of system, where pre-commit will give up on managing a virtual environment, there are no guarantees it will be activated.

So that means deptry works fine when I call from a terminal with active venv either deptry . or pre-commit run deptry but not as a pre-commit git hook.

This is why I've been using language: python as a hack.

[maciejb]

One other reason to move to a language: python setup would be for compatibility with https://pre-commit.ci/ .. definitely would be a nice-to-have!