Mypy should be able to access real dependencies

I am not sure how to better achieve it. Here is the particular problem: my project uses attrs library, and in particular its new attr.s(auto_exc=True) flag. This flag appeared in the last version of attrs and didn’t yet make its way into attrs typeshed which is shipped with mypy (at mypy/typeshed/third_party/2and3/attr). Now, when I use pre-comit to run mypy, it works in its own virtualenv and does not have my dependencies installed. When it tries to find definitions for attrs, it finds that it cannot import such module but it finds that shipped typeshed and uses it. This results in an error being thrown at me regarding unknown auto_exc argument.

At least I would like to be able to at least prohibit mypy using these third-party typesheds. And at most it would be great to allow mypy used by pre-commit to access real package’s dependencies installed. Here are approaches I see:

1. We could do something like pip install -e . before actually running mypy. But it will install stuff into pre-commit global mypy virtualenv which might be not good when working on multiple projects.
2. We could make some exception to make pre-commit use my per-project virtualenv. Personally I use path/to/project/env directory, but it should be configurable somehow. And that configuration should not be committed to the repo because my colleagues might prefer different virtualenv locations.
3. Looks like --python-executable path/to/virtual/env/bin/python argument to mypy helps, but how do we make actual path not being committed to the repo?

[douardda]

Hi, I am facing the same kind of problem. How can I use this mypy pre-commit hook on real-life use cases? I mean I definitively do not want to duplicate my requirements (with extras) in the additional_dependencies config entry, and the ‘language: system’ trick is not really acceptable to me since. as @asottile noticed, it makes the pre-commit hook result depends on the local (aka ‘system’) development venv (in which can live many more packages than what’s listed in my project’s requirements.)

In the end, and this is quite specific to mypy I guess, it makes no sense to run mypy on the local copy of the code in a dedicated venv if the dependencies of said code are not also installed in that venv, and it seems to me not really acceptable to workaround this by maintaining the additional_dependencies entry ‘by hand’.

I guess this is more a limitation of pre-commit itself, but it really reveals itself with mypy. Not sure what to do from there.

edit: I do understand there are also difficulties coming from the caching system of pre-commit.

[rmorshea]

Good to know. Looking into this more it seems like running mypy via a language: system command might resolve this issue, if not most use cases for a requirements.txt file. Will need to try that out though.