Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mypy alternates between "error: Skipping analyzing" and no errors #11010

Closed
NiklasRosenstein opened this issue Aug 23, 2021 · 3 comments
Closed

Mypy alternates between "error: Skipping analyzing" and no errors #11010

NiklasRosenstein opened this issue Aug 23, 2021 · 3 comments
Labels
bug mypy got something wrong

Comments

@NiklasRosenstein
Copy link

NiklasRosenstein commented Aug 23, 2021 •
edited
Loading

Bug Report

I have in my environment a bunch of packages in the nr namespace packages (e.g. nr.preconditions, nr.stream, nr.optional, etc.). When using Mypy to check my package, every other invokation (starting with the first time), it shows errors that the type hints for the nr module cannot be found.

image

The nr.* packages I listed above and also the databind packages check out with Mypy individually. It seems that only every other invokation, Mypy understands that it doesn't need to look for type hints for nr because it is just a namespace package. The nr/__init__.py file is the same for all of these packages with the following content:

__path__ = __import__('pkgutil').extend_path(__path__, __name__)  # type: ignore

What also surprises me is that Mypy seems to be checking the validity of dependencies? (I.e. source code in .venv) My understanding was that Mypy axiomatically assumes the correctness of type hints in dependencies and only fully checks static typing in the files/directories specified on the CLI.

To Reproduce

I'm having a bit of a hard time to find a small example to reproduce this issue consistently. The project where I experience this is internal, so I can't share the entire project. Until I find a definitive reproduction scenario, happy to take any advice or answer questions.

Expected Behavior

Mypy does not look for type hints for the nr namespace.

Your Environment

  • Mypy version used: 0.910
  • Mypy command-line flags: n/a
  • Mypy configuration options from mypy.ini (and other config files): n/a
  • Python version used: 3.9.6
  • Operating system and version: OSX
@NiklasRosenstein NiklasRosenstein added the bug mypy got something wrong label Aug 23, 2021
@aberres
Copy link

aberres commented Aug 23, 2021

Maybe related to #9852?

@NiklasRosenstein
Copy link
Author

Thanks @aberres , it does seem related. Adding --no-incremental as suggested in the linked issues also makes it work consistently for me.

@hauntsaninja
Copy link
Collaborator

This should be fixed on latest master (please re-open if can still repro!)

bonzini pushed a commit to qemu/qemu that referenced this issue Nov 1, 2021
@jnsnow
iotests/linters: Add workaround for mypy bug #9852
558dbe9 
This one is insidious: if you write an import as "from {namespace}
import {subpackage}" as mirror-top-perms (now) does, mypy will fail on
every-other invocation *if* the package being imported is a typed,
installed, namespace-scoped package.

Upsettingly, that's exactly what 'qemu.[aqmp|qmp|machine]' et al are in
the context of Python CI tests.

Now, I could just edit mirror-top-perms to avoid this invocation, but
since I tripped on a landmine, I might as well head it off at the pass
and make sure nobody else trips on that same landmine.

It seems to have something to do with the order in which files are
checked as well, meaning the random order in which set(os.listdir())
produces the list of files to test will cause problems intermittently
and not just strictly "every other run".

This will be fixed in mypy >= 0.920, which is not released yet. The
workaround for now is to disable incremental checking, which avoids the
issue.

Note: This workaround is not applied when running iotest 297 directly,
because the bug does not surface there! Given the nature of CI jobs not
starting with any stale cache to begin with, this really only has a
half-second impact on manual runs of the Python test suite when executed
directly by a developer on their local machine. The workaround may be
removed when the Python package requirements can stipulate mypy 0.920 or
higher, which can happen as soon as it is released. (Barring any
unforseen compatibility issues that 0.920 may bring with it.)

See also:
 python/mypy#11010
 python/mypy#9852

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Message-id: 20211019144918.3159078-14-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
stsquad pushed a commit to stsquad/qemu that referenced this issue Nov 2, 2021
@jnsnow @stsquad
iotests/linters: Add workaround for mypy bug #9852
30aca41 
This one is insidious: if you write an import as "from {namespace}
import {subpackage}" as mirror-top-perms (now) does, mypy will fail on
every-other invocation *if* the package being imported is a typed,
installed, namespace-scoped package.

Upsettingly, that's exactly what 'qemu.[aqmp|qmp|machine]' et al are in
the context of Python CI tests.

Now, I could just edit mirror-top-perms to avoid this invocation, but
since I tripped on a landmine, I might as well head it off at the pass
and make sure nobody else trips on that same landmine.

It seems to have something to do with the order in which files are
checked as well, meaning the random order in which set(os.listdir())
produces the list of files to test will cause problems intermittently
and not just strictly "every other run".

This will be fixed in mypy >= 0.920, which is not released yet. The
workaround for now is to disable incremental checking, which avoids the
issue.

Note: This workaround is not applied when running iotest 297 directly,
because the bug does not surface there! Given the nature of CI jobs not
starting with any stale cache to begin with, this really only has a
half-second impact on manual runs of the Python test suite when executed
directly by a developer on their local machine. The workaround may be
removed when the Python package requirements can stipulate mypy 0.920 or
higher, which can happen as soon as it is released. (Barring any
unforseen compatibility issues that 0.920 may bring with it.)

See also:
 python/mypy#11010
 python/mypy#9852

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Hanna Reitz <hreitz@redhat.com>
Message-id: 20211019144918.3159078-14-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug mypy got something wrong
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@NiklasRosenstein @hauntsaninja @aberres