in-project stubs cause mypy to bail in 0.971

[vfazio]

Bug Report

We have a project that includes type stubs for a python package that does not provide it's own typing. We followed guidance per https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-library-stubs-or-py-typed-marker number 3

(venv) vfazio@vfazio2 ~/development/xtf $ grep mypy_path mypy.ini
mypy_path=$MYPY_CONFIG_FILE_DIR/stubs

In mypy 0.961, type checks pass

(venv) vfazio@vfazio2 ~/development/xtf $ mypy -V; mypy xes/
mypy 0.961 (compiled: no)
Success: no issues found in 86 source files

In mypy 0.971, these now fail because the current path is being added to the path search

(venv) vfazio@vfazio2 ~/development/xtf :( $ mypy -V; mypy xes/
mypy 0.971 (compiled: no)
['/mnt/development/mypy/venv/lib/python3.10/site-packages', '/mnt/development/xtf']
/mnt/development/xtf is in the MYPYPATH. Please remove it.
See https://mypy.readthedocs.io/en/stable/running_mypy.html#how-mypy-handles-imports for more info

If i modify mypy/pyinfo.py::getsearchdirs to exclude the current working directory (effectively reverting 2132036) the type checks "work" except I now get type failures for the stubs

(venv) vfazio@vfazio2 ~/development/xtf $ mypy -V; mypy xes/
mypy 0.971 (compiled: no)
stubs/redacted/path/file.pyi:49:9: error: Function is missing a return type annotation  [no-untyped-def]
stubs/redacted/path/file.pyi:49:9: note: Use "-> None" if function does not return a value
<snip>
Found 58 errors in 2 files (checked 86 source files)

Expected Behavior

Failures wouldn't occur or documentation would be updated to reflect how to accommodate this use case.

Actual Behavior

mypy now fails to type check our code because we include stubs as part of our source tree

Your Environment

• Mypy version used: 0.971
• Mypy command-line flags:
• Mypy configuration options from mypy.ini (and other config files):
• Python version used: 3.10.4
• Operating system and version: Ubuntu 20.04

[hauntsaninja]

In mypy 0.960 and for long, long before, mypy only looked at site packages, with some logic on top to handle .pth files.
The big change here was #11143 , which changed that so mypy looks at most of sys.path.

The check you're running into was to prevent people from doing MYPYPATH=/whatever/python/site-packages, which would do terrible things (at least historically — that check is really really old and things might be better today).

If you see the before side of #11143, this check was only against site_packages, not egg_dirs (which is where the .pth stuff, such as an editably installed cwd, would go). The right side of #11143 smooshes all of sys.path together, which is why you now get this check. This seems bad.

The connection with errors being reported in your stubs comes from

mypy/mypy/build.py

Line 2458 in a6166b2

for dir in manager.search_paths.package_path + manager.search_paths.typeshed_path:

where mypy will automatically silence errors from things it's picked up from pyinfo and typeshed.

Just to be explicit and reduce confusion, I'm quite sure the current pyinfo / #13161 is correct (and it matches the behaviour of mypy 0.960 too, in terms of what ends up where on SearchPaths).
The issue described by OP isn't really with cwd — it can happen with any directory that is on sys.path and MYPYPATH.

I think the fix here is to either get rid of the check entirely, or to restrict it so that it only applies to actually site-package dirs, like it did in 0.960

[hauntsaninja]

And thanks for the report and the extra investigation, makes it much easier to figure out what's going on!

[vfazio]

Ok, I think I kinda-sorta understand what's going on.

As a test, I reverted my hack to exclude cwd and dropped the sys.exit(1) from modulefinder after the MYPYPATH warning and I now see that the .pyi files no longer trigger warnings.

For now, we'll stick to 0.961 until there's a patch to address this behavior.

It may make sense to add a unittest for this scenario since it's a documented configuration, that way any future regressions could be caught?

[uSpike]

I think I've found the specific environment parts that are causing our error.

• We use poetry
• We have a namespace package and use the packages feature: https://python-poetry.org/docs/pyproject/#packages
• mypy.ini contains mypy_path=$MYPY_CONFIG_FILE_DIR/stubs

So our pyproject.toml looks like:

[tool.poetry]
name = "test_project"
...
packages = [
    { include = "namespace_pkg" }
]

Upon poetry install, a test_project.pth file is created in <virtualenv path>/lib/python3.10/site-packages/:

 $ ls <redacted>/lib/python3.10/site-packages/ -la                                                                                                                        
...                                                            
-rwxr-xr-x  1 jspeicher domain users 45790632 Jul 22 11:19 f4771e8a540c98c8e0df__mypyc.cpython-310-x86_64-linux-gnu.so
drwxr-xr-x  9 jspeicher domain users    12288 Jul 22 11:19 mypy
drwxr-xr-x  2 jspeicher domain users     4096 Jul 22 11:19 mypy-0.971.dist-info
drwxr-xr-x  2 jspeicher domain users     4096 Jul 22 11:19 mypy_extensions-0.4.3.dist-info
-rw-r--r--  1 jspeicher domain users     5078 Jul 22 11:19 mypy_extensions.py
drwxr-xr-x 14 jspeicher domain users     4096 Jul 22 11:19 mypyc
...
drwxr-xr-x  2 jspeicher domain users     4096 Jul 22 11:20 test_project-0.1.0.dist-info
-rw-r--r--  1 jspeicher domain users       30 Jul 22 11:20 test_project.pth
...

With this test_project.pth file, mypy errors as @vfazio commented.

$ mypy namespace_pkg
<project dir> is in the MYPYPATH. Please remove it.

If I comment-out the packages portion of pyproject.toml then the test_project.pth file is not created, and mypy works as expected.

---

I also tried this with a simple setuptools-based setup:

setup.py:

from setuptools import setup

setup(
   name='test_project',
   version='2.0',
   packages=['namespace_pkg'],
)

Upon pip install -e ., a venv/lib/python3.10/site-packages/test-project.egg-link file is created, which causes the same mypy error:

$ mypy namespace_pkg
<project dir> is in the MYPYPATH. Please remove it.

[uSpike]

To sum up my previous comment, I think that mypy is currently incompatible with an editable-installed package (pip install -e .) in combination with mypy config mypy_path=$MYPY_CONFIG_FILE_DIR/<anything>