Q: using mypy in virtual environments

[thmsklngr]

Hi,

I have a question about mypy usage in virtual environments. I'm running my development jobs on a Mac and thus I have installed mypy globally, but everything else I need for a project in a virtual environment. This ends up in a mess, of course. mypy complains that it won't find modules, which are installed only in this specific environment, but I don't want to install mypy in every single development environment I have.

What's a possible solution? I tried to modify mypy in setting up a setup.cfg in the root of a project, but this ends up with an internal error.

In addition it would be great if someone knows how to use mypy in Atom as well in virtual environments.

Please advice. Many thanks in advance!

Regards, Thomas

[emmatyping]

Hi! You can use the --python-executable path/to/python so mypy will use the virtual environment for that executable.

You shouldn't run into an internal error, so if you could provide steps to reproduce that, it would be greatly appreciated.

[thmsklngr]

Hi,
I tried what you suggested, but, nope, it's not working:

$ mypy --python-executable ./env/bin/python -p stocksportevents
stocksportevents/main/forms.py:1: error: Cannot find module named 'flask_wtf'
stocksportevents/main/forms.py:2: error: Cannot find module named 'wtforms'
stocksportevents/main/forms.py:10: error: Cannot find module named 'wtforms.widgets'
...

stocksportevents is a package made for Flask. I tried it several ways, with activated environment and also without activated environment, always starting from the application root.

Any hints what I'm doing wrong?

Regards, Thomas

[thmsklngr]

I continued troubleshooting this and it gets more weird. I uninstalled mypy globally (located in /usr/local/lib/python3.7/site-packages) and installed it locally to that virtual environment. Even there when started from within the application root with all virtual environment variables I get the same errors that modules can't be found, even though they're there.

Regards, Thomas

[emmatyping]

Ah, it is likely that these projects do not provide type information, so mypy can't use them. I do see how this message could be rather confusing. You will need to ignore these errors. See https://mypy.readthedocs.io/en/latest/common_issues.html#spurious-errors-and-locally-silencing-the-checker and https://mypy.readthedocs.io/en/latest/installed_packages.html. You may also want to read the getting started section of the docs as well.

@JukkaL what do you think of changing the error to something like Cannot find types in module named '<module>'?

[thmsklngr]

Ah, ok, I see, in that way it then makes sense. The error message is indeed misleading in many ways.

Sorry for the inconveniences!

Regards, Thomas

[ilevkivskyi]

@ethanhs I would rather add a note (once per module) saying roughly something like: If this a third party library, check if you have type stubs or typed package (or similar). And maybe also a link to the docs (I think we already show it in some cases).

[emmatyping]

@ilevkivskyi sure that sounds good to me 👍

[benknoble]

A bit late, but can you explain the difference between these?

error: No library stub file for module 'tensorflow'
error: No library stub file for module 'sklearn'
error: No library stub file for module 'sklearn.model_selection'
error: Cannot find module named 'imblearn'

The first three seem to say "no type information"—the last says "no module" (to
my interpretation).

This is a run in a python3 -m venv setup, where I have definitely installed
all of these, including imblearn:

>>> import imblearn
>>> # silence is golden

[hauntsaninja]

Closing as a duplicate of #4542