-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Fail fast if special module like typing not from typeshed #1876
Comments
We apologize for the crash and will look into producing a more meaningful error message. Is the file typing.py that you have a copy of the official typing.py file or an unrelated file with an unfortunate name clash? When analyzing a package and its dependencies it's usually best not to include site-packages -- there's an explicit warning about this in the docs (see the very bottom of http://mypy.readthedocs.io/en/latest/basics.html). |
The first example simulates the "unfortunate name clash" case, contents of the file displayed. The second example it is the official typing.py taken from git master shortly before I posted this issue. Note that in neither case did I explicitly set MYPYPATH. Just referencing a file in the site-packages directory (which implicitly adds it to the search path) is sufficient. I ran into this while setting up mypy for the first time after having added the venv site-packages to the MYPYPATH variable in response to the tremendous number of import errors from the first run for libraries that I knew were installed. I only read I thought it would be reasonable to "whitelist" site-packages that were known to be analyzable, with an invocation like |
Yeah, the feature of automatically adding the parent directory to the import path fails spectacularly for site-packages -- perhaps we should just exclude site-packages from this behavior even if we preserve it for other locations (because it is often truly useful as well!). We've also discussed the idea of a flag that adds a stdlib module to the packages to be analyzed (without this auto-path-setting behavior). When you have a tremendous number of failing imports, you may also consider |
Yeah, I started using |
Actually typing.py is probably the exception. What does -v output for a single file? There's a little cycle of dependencies around builtins (at least builtins, typing, and abc) but typically these are gotten from typeshed stubs, not from .py files. |
Is this what you wanted?
|
That one's not so surprising because you pass a bogus typing.py on the
command line -- this gets substituted for the stub in typeshed so that
whatever builtins needs from typing isn't there, and hence the crash.
I thought that you were reporting problems when passing foo.py on the
command line where there's a bogus typing.py in the same directory when
also passing -s.
Also, what version of mypy? I can repro this with 0.4.3-dev but not with
0.4.3.
|
Here's the case with that same typing.py alongside an empty hello.py with 0.4.3:
And here's git master, same file setup:
|
Hm, the only reasonable way that I can think to avoid such crashes is to
explicitly check that the stub for typing, builtins and everything else in
that initial import cycle is actually loaded from typeshed. Hopefully you
can work around it now!
|
Was there a workaround for wanting to include a venv dependency in the analysis? Or is that future work |
That's future work -- a cumbersome workaround would be to just download and
untar the tarball (or unzip the zipfile) for the package's source distro,
or clone the repo, and point mypy at the package in the source tree. For
most reasonable source distributions that should work.
|
See PR #1895 -- once that lands anybody can install typeshed additions. |
I don't think finding a solution that avoids the initially-reported crash has much priority. When you feed mypy the wrong typing.py (or builtins.py, or whatever) it's going to be unhappy. So I'm moving the milestone up. |
Random idea: I wonder if we should have a separate panic() function for reporting problems like this (notably things missing from the builtins), so that they are clearly distinguished from other crashes? |
I propose to close this as "won't fix" since we're unlikely to be fixing crashes due to the presence of incorrect stubs for builtins and typing. |
What about checking that typing and builtins come from typeshed? |
Sure. (And their dependencies, I suppose -- I have "_importlib_modulespec,abc,types,builtins,typing,sys" listed for PY3. If you want that in this same issue please rename the issue subject. |
typing.py
Ok, renamed. Let's continue to use this issue. |
This has regressed again. If you do something like (Additionally something changed between 0.790 and 0.812 that caused mypy to start picking up |
v0.800 made a number of changes to source finding behaviour, in particular recursively finding code that we used to not find. v0.812 has a new flag |
Even though |
@JukkaL this issue seems to be open. Can you assign it to me? |
Feel free to work on it. No one really takes issue assignment in mypy to mean anything |
It should work now with custom-typeshed-dir and use_builtins_fixtures. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes python#1876
It should work now with custom-typeshed-dir. Fixes #1876
mypy generally crashes with an internal error if it winds up trying to handle a file named
typing.py
, apparently due to confusion with the built-intyping
module. Here's the simplest test case I've found (tested on 0.4.3 and master):This is the same error message reported in a comment in #1293. The root cause is that mypy ships a file called typing.py in site-packages, so if site-packages winds up on the path (even implicitly, even with -s), it dies:
This makes it impossible to analyze a package along with even a subset of its dependencies as the implicit addition to MYPYPATH results in an internal error.
The text was updated successfully, but these errors were encountered: