Relative imports from within the same package lead to "no type hints or stubs" error

[mschmidt87]

Hi,

I have a problem with mypy and handling of imports. Basically, I have a Python package with several modules which import other modules of the package. When I run mypy (version 0.770) on the files, I get this error:
error: Skipping analyzing '.file2': found module but no type hints or library stubs

However, I don't understand that error message because (in this example) file2 does contain type hints.
For the purpose of this issue, I have created a minimal reproducer. I have two files file1 and file2 which both define a class. The class in file1 (Example1) has a method which uses the class from file2 (Example2), thus file1 imports file2 with a relative import (from .file2 import Example2). This is the full code:

• file1.py

from .file2 import Example2

class Example1:
    def __init__(self, value: float) -> None:
        self.value = value

    def add(self, other: Example2) -> None:
        self.value += other.value

• file2.py

class Example2:
    def __init__(self, value: float) -> None:
        self.value = value

When I run mypy file1.py file2.py, I am receiving the error mentioned above:

file1.py:1: error: Skipping analyzing '.file2': found module but no type hints or library stubs
file1.py:1: note: See https://mypy.readthedocs.io/en/latest/running_mypy.html#missing-imports

Now I did visit that recommended link in the documentation but I couldn't figure out how to solve my problem.

However, one thing that worked was to turn the relative into a global import, i.e. to write from file2 import Example2. However, I would like to avoid that because in my package I would prefer to use relative imports for ease of readability of the code (amongst others). Also, the error message does not seem to make sense to me because file2.py does contain type annotations.

Apologies for posting this because it seems like a basic thing, but I couldn't figure it out with the documentation or by browsing the issues here.
It would be great if someone could explain how to do this properly or point me to a documentation of the solution.
Thanks a lot.

(Python version if 3.8.2).

[msullivan]

mypy expects a __init__.py in the directory in order for it to be a package.

[mschmidt87]

Thank you for your reply. Sorry, I forgot to mention that: I did add an __init__.py in the same folder but it led to the same result. I tried both an empty file or this:

from . import file1
from . import file2

but I got the same error.

[msullivan]

Oh, hm. Mypy doesn't want you specifying paths to modules in packages without a directory component of the path name, it seems. Running from the parent directory and specifying the paths, works, I think.

[mschmidt87]

Okay, if I understood you correctly, you want me to move one level up (to the parent dir) and call mypy from there? That actually works with the relative imports.

To be clear, what I did was: The code posted above is in a folder mypy_min_reproducer. Then I do

cd mypy_min_reproducer
cd ..
mypy mypy_min_reproducer/file1.py mypy_min_reproducer/file2.py

and receive Success: no issues found in 2 source files.

Thanks a lot for the tip. However, the error message is not very informative here, could it be improved?

[JukkaL]

Marked this as a usability issue. The error message isn't very helpful.

[bsmedberg-xometry]

Is this ticket about fixing the error message, or fixing the mypy behavior not to require an __init__.py file? As of python 3.3, init.py is no longer required for packages.

[hauntsaninja]

I think the correct fix here is that we should make find_sources use absolute paths when crawling. I had a diff that did this, but all the tests use relative paths so it broke everything; I'll try again by converting back to relative paths for BuildSource.

Note that this behaviour was documented as a result of #6660, but I traced it all the way back to 0555178 and I don't see a good reason to treat relative paths differently. This has come up in some other issues as well.

Secondarily, we might be able to make some improvements to modulefinder's error messages.

Finally, mypy's handling of __init__.py-less packages isn't ideal (for now, my recommendation is to use mypy -p <package> --namespace-packages), but I've recently made some PRs reworking things, so mypy 0.800 will be better.