Having a `packages` property in pyproject.toml makes mypy no longer check types in imports after installing the package with Poetry

[Newbytee]

Bug Report

I've been having the issue that Mypy suddenly no longer type checks the contents of my imports, even though they are in the same source tree. After bisecting the issue, I figured out that the cause was the addition of the packages line to my pyproject.toml file by a co-worker. This behaviour is strange to me, so it seems like a bug likely in mypy?

To Reproduce

pyproject.toml:

[tool.poetry]
name = "mypy-issue-reproducer"
version = "0.1.0"
description = ""
authors = ["Your Name <[email protected]>"]
readme = "README.md"
packages = [
    { include = "**/*.py" },
]

[tool.poetry.dependencies]
python = "^3.10"

[tool.poetry.group.dev.dependencies]
mypy = "^1.8.0"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

reproducer-main.py:

from some_module.reproducer_import import main

main()

some_module/reproducer-import.py:

def main():
    # blatant violation
    variable: str = 1

README.md also needs to be created and can contain whatever.

Creating these files and installing the project with $ poetry install --with dev, then running $ poetry run mypy reproducer-main.py reproduces the issue (note how mypy does not complain about the blatant type violation in reproducer-import.py). Removing the packages property, then removing the virtualenv and repeating the install and Mypy steps now has Mypy actually report the aforementioned type violation.

If you just want a git repository to clone, here you go: https://github.com/Newbytee/mypy-bug-reproducer

Expected Behavior

Mypy type checks the main function in reproducer-import.py.

Actual Behavior

Mypy does not care that the main function in reproducer-import.py has a blatant type violation:

$ poetry run mypy reproducer-main.py 
Success: no issues found in 1 source file

Your Environment

• Mypy version used: 1.8.0 (compiled: yes)
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): None
• Python version used: Python 3.10.12

This happens both in my Ubuntu 22.04 LTS container and also my CI using both the python:3.10 image and the python:3.11 image.

[Newbytee]

Since writing this I've realised something notable: Using $ poetry install --no-root instead of $ poetry install works around the problem. --no-root stops Poetry from installing the current project.

For our internal code, I wrote the following about this workaround as a commit message:

To my understanding, this is the problem:

 - poetry install, by default, will try to install the current project
   as a Python package.
 - Mypy only wants to check the typings in your current project, and
   not the given module's entire dependency tree since that likely
   would result in hundreds of errors across the given module's
   dependency tree which the programmer has no ability to fix in a
   reasonable way short of contributing fixes upstream.

As such, when the project gets installed by Poetry, Mypy considers all
the imports to be part of the dependency tree and not the project itself
since the current project gets installed as a package. Subsequently,
Mypy doesn't bother type checking the imports, so you have to manually
specify every file you want checked.

But I don't know much about the actual inner workings of Poetry and Mypy. Would be nice to hear some other people's thoughts about this.