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.

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

"Intermittent" import error when checking a module that import another module which imports a 3rd party package #7276

Closed
Quibi opened this issue Jul 31, 2019 · 12 comments
Labels

Comments

@Quibi
Copy link

Quibi commented Jul 31, 2019

Hi,

Sorry for the title. I try to explain myself better.

I have found a strange behaviour in mypy related to an import error in a imported module. That is, an error in a module 'b' importing a module 'c' while checking module 'a', which imports 'b'. 'c', of course, is a 3rd party package.

In such a case, mypy reports nothing on a first round. But if it is run again, it reported a error: Cannot find module named 'c'. On a third run, nothing is reported again, while on a fourth run the error re-appears, and so on...

This happens even when the type check has been disabled in the import line.

A possible scenario to reproduce this "bug" is as follows:

  1. Create a 'strange_report' package (with an empty __init__.py).

  2. Create a subpackage called 'a' inside 'strange_report' (with an empty __init__.py too).

  3. Write an a.py module (importer module) such as:

from a.b import B

b = B()  # just for visually check that a.py was run
  1. Write a b.py module (imported module)
from ruamel.yaml import YAMLError  # type: ignore


class B:
    def __init__(self):
        print(f"New 'B' object {self} has been created")
  1. Open terminal and change to directory 'strange_report'.

  2. Module a.py can be run with python -m a.a

  3. If you run mypy a/a.py for the first time, you do not get any reports (however, directory '.mypy_cache' is created).

  4. But if you run mypy a/a.py once again, you get an error:

madera:strange_error jv$ mypy a/a.py
a/b.py:1: error: Cannot find module named 'ruamel'
a/a.py:1: error: Cannot find module named 'ruamel'
a/a.py:1: note: See https://mypy.readthedocs.io/en/latest/running_mypy.html#missing-imports
  1. You can repeat 7. and 8. again and again with similar results. Same results are gotten with or without # type: ignore.

However, if cache directory '.mypy_cache' is deleted before running mypy every time, it does not report anything.

Curiously enough, if you check mypy a/b.py it consistently reports nothing.

I am running on:

  • macOS HIgh Sierra 10.13.6
  • Python 3.7.4
  • mypy 0.720
  • ruamel.yaml 0.16.0 (so, yes, ruamel.yaml is installed; I use this 3rd party package because it is causing the bug in my system; no any particular purposes, I imagined that same bug can appeared with similar packages but cannot confirm that)
  • Any mypy configuration beyond the default one.

Thank for your attention. I hope that will be helpful.

@ilevkivskyi
Copy link
Member

Thanks for reporting! Does this also happen with --ignore-missing-imports?

@Quibi
Copy link
Author

Quibi commented Sep 9, 2019

Oh, I am sorry. I missed your request.

mypy a/a.py --ignore-missing-imports does not raised the error.

Indeed, this is even more puzzling since according to documentation:

This flag makes mypy ignore all missing imports. It is equivalent to adding # type: ignore comments to all unresolved imports within your codebase.

Do not --ignore-missing-imports CLI argument and # type: ignore should cause the same error (or any error at all)?

Thank you.

@jsonmcfall
Copy link

We hit this error at least several times a day.
It seems to alway show up with:
AssertionError: Cannot find module for ruamel

@JukkaL
Copy link
Collaborator

JukkaL commented Oct 7, 2019

Does using --no-incremental get rid of the issue?

@Quibi
Copy link
Author

Quibi commented Oct 7, 2019

@jmcfallargo Of course, you must install ruamel.yaml first: https://pypi.org/project/ruamel.yaml/

It is just an example. I suspect that this issue can appear with other packages too, but I could not confirm that -- so I use this one in particular in my example.

@Quibi
Copy link
Author

Quibi commented Oct 7, 2019

@JukkaL No issues with mypy a/a.py --no-incremental (in mypy 0.730). It is the same as deleting the cache by hand if I correctly understand the documentation. But this does not solve the issue, does not it?

Thank you.

@JukkaL
Copy link
Collaborator

JukkaL commented Oct 8, 2019

It is the same as deleting the cache by hand if I correctly understand the documentation

Correct.

But this does not solve the issue, does not it?

Yeah, it doesn't solve the issue.

I'm increasing priority, at least until we better understand why (or how frequently) this happens, since incremental mode issues can be painful to diagnose and work around.

@Quibi
Copy link
Author

Quibi commented Oct 10, 2019

Thank you, @JukkaL Sorry for not being able to provider further insights on this issue.

@asfaltboy
Copy link

I think what makes ruamel.yaml package "special" is that it uses the ruamel namespace (namely a directory in e.g site-packages with no __init__.py.

Could it be that we're not using the PEP 420 traversal (added by Barry Warsaw in PR #7219) since we're not targetting this package directly?

Back Ref: I had reported a similar issue with ruamel here: https://bitbucket.org/ruamel/yaml/issues/328/mypy-complains-that-ruamel-is-missing-type

@domdfcoding
Copy link
Contributor

For future reference the issue @asfaltboy linked to is now at https://sourceforge.net/p/ruamel-yaml/tickets/328/

hauntsaninja pushed a commit to hauntsaninja/mypy that referenced this issue Oct 24, 2020
Unfortunately, a number of tests fail. Please help fixing them :-)
Especially the ones to do with cache inconsistencies... There's at least
one known bug here: python#7276
CaptainAchab pushed a commit to TankerHQ/sdk-python that referenced this issue Dec 17, 2020
@hauntsaninja
Copy link
Collaborator

Fixed by #10937

hauntsaninja pushed a commit to hauntsaninja/mypy that referenced this issue Aug 6, 2021
Unfortunately, a number of tests fail. Please help fixing them :-)
Especially the ones to do with cache inconsistencies... There's at least
one known bug here: python#7276
SamTheisens added a commit to Vandebron/mpyl that referenced this issue Sep 13, 2023
python/mypy#7276

branch: feature/TECH-491-support-release-candidates
SamTheisens added a commit to Vandebron/mpyl that referenced this issue Sep 13, 2023
python/mypy#7276

branch: feature/TECH-491-support-release-candidates
SamTheisens added a commit to Vandebron/mpyl that referenced this issue Sep 13, 2023
python/mypy#7276

branch: feature/TECH-491-support-release-candidates
SamTheisens added a commit to Vandebron/mpyl that referenced this issue Sep 13, 2023
python/mypy#7276

branch: feature/TECH-491-support-release-candidates
@sigma67
Copy link

sigma67 commented Mar 15, 2024

I am still seeing this issue with ruamel pulled in via another dependency. mypy 1.9.0

--no-incremental fixes it

dkfellows added a commit to dkfellows/hpcflow-new that referenced this issue Jun 20, 2024
bherrera pushed a commit to misttech/mist-os that referenced this issue Jul 15, 2024
Add `--no-incremental` flag to mypy config to temporarily resolve a flake where mypy is unable to find the Honeydew module.

See python/mypy#7276 for details on a similar issue.

Run-All-Tests: True

Bug: 345717802
Change-Id: I7dff3c4cf5405bf387ffae2802c4b25ff0553f56
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1078421
Reviewed-by: Kevin Cho <chok@google.com>
Commit-Queue: Mahesh Saripalli <maheshsr@google.com>
Fuchsia-Auto-Submit: Mahesh Saripalli <maheshsr@google.com>
bherrera pushed a commit to misttech/integration that referenced this issue Jul 16, 2024
… resolve mypy flake

Add `--no-incremental` flag to mypy config to temporarily resolve a flake where mypy is unable to find the Honeydew module.

See python/mypy#7276 for details on a similar issue.

Run-All-Tests: True

Original-Bug: 345717802
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1078421
Original-Revision: 9b5d6807bce05e989e9f7b7afad1430ae4e385ad
GitOrigin-RevId: 589ac95b4deca50ca969dadee998a7c244fc6168
Change-Id: I80a6a62dc964f333f8b78d0fc121642ac6dabfd1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants