so.. weird one.. added mypy one mergerequest ago. used a lockfile, added some .pyi stubs for a library, all working. CI built and deployed. 👍 great Today, adding isort. same deal, everything (test, check, lint) working locally. But now mypy when running in CI is complaining about no stubs. looks like mypy fails when i'm using

--changed-since

╭─xlevus@xd1 ~/Projects/_mono  ‹feat/isort› 
╰─➤  ./pants check --changed-since=origin/master                                                                                                         1 ↵
11:15:00.85 [INFO] Completed: Extracting 3 requirements to build requirements.pex from repository.pex: docker, requests, six
11:15:02.36 [INFO] Completed: Building requirements_venv.pex
11:15:04.27 [ERROR] Completed: Typecheck using MyPy - MyPy failed (exit code 1).
build-support/deploy/docker_.py:3: error: Skipping analyzing "docker": found module but no type hints or library stubs
build-support/deploy/docker_.py:3: note: See <https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports>
build-support/deploy/docker_.py:4: error: Skipping analyzing "docker.errors": found module but no type hints or library stubs
build-support/deploy/docker_.py:5: error: Skipping analyzing "docker.models.images": found module but no type hints or library stubs
Found 3 errors in 1 file (checked 6 source files)



𐄂 MyPy failed.
╭─xlevus@xd1 ~/Projects/_mono  ‹feat/isort› 
╰─➤  ./pants check ::                                                                                                                                    1 ↵
11:15:13.10 [INFO] Completed: Typecheck using MyPy - MyPy succeeded.
Success: no issues found in 18 source files



✓ MyPy succeeded.
╭─xlevus@xd1 ~/Projects/_mono  ‹feat/isort› 
╰─➤  ./pants --version
2.8.0rc6

I think you also need

--changed-dependees=transitive

oh, that'd certainly help for an edge-case I've missed where updating A might break the type signatures on B. But in this case, the

.pyi

files haven't changed. And it still fails with

transitive

Thank you for the bug report and reproduction! I don't think I'll have a chance to get to this today, but setting a reminder for tomorrow In the meantime, I wonder if

__init__.py

without the

i

works? I definitely think our special-casing of

__init__.py

is not operating on

__init__.pyi

- pure oversight

it does not look like it