Cannot find builtins (when installing from a tarball?)

[xlorepdarkhelm]

I pulled the most recent version from git today in order to make mypy work. However, when I run the following:

> mypy pampas/core/common.py

I get the result:

pampas/__init__.py:1: error: Could not find builtins

I found the following closed issue: #389 which seemed similar, but the solution given (sudo chmod -R go+rX /usr/local/lib/mypy) did not work for me.

Interestingly, if I change to the pampas/core path, and execute:

> mypy common.py

it seems to work:

common.py: note: In class "Plugin": common.py:1318: error: Parse error before "async" common.py:1318: error: Parse error before : common.py:1319: error: Inconsistent indentation common.py: note: At top level: common.py:1751: error: Inconsistent indentation common.py: note: In class "ListEntryGenerator": common.py:2423: error: Parse error before "def" common.py:2423: error: Parse error before : common.py:2424: error: Inconsistent indentation common.py:2425: error: Parse error before "self" common.py: note: At top level: common.py:2428: error: Parse error before "def" common.py:2428: error: Parse error before : common.py:2429: error: Inconsistent indentation common.py:2437: error: Parse error before "task" common.py:2442: error: Inconsistent indentation common.py: note: In class "ListEntry": common.py:2776: error: Parse error before "async" common.py:2776: error: Parse error before : common.py:2777: error: Inconsistent indentation common.py:2793: error: Parse error before "loop" common.py: note: At top level: common.py:2909: error: Parse error before "async" common.py:2909: error: Parse error before : common.py:2910: error: Inconsistent indentation common.py:2922: error: Parse error before "loop" common.py:2924: error: Inconsistent indentation common.py:3041: error: Parse error before "async" common.py:3041: error: Parse error before : common.py:3042: error: Inconsistent indentation common.py:3052: error: Parse error before "cls" common.py:3052: error: Parse error before : common.py:3053: error: Inconsistent indentation common.py:3055: error: Inconsistent indentation common.py:3057: error: Inconsistent indentation common.py:3057: error: Parse error before : common.py:3058: error: Inconsistent indentation common.py:3076: error: Inconsistent indentation

So I am thinking it has something to do with trying to call mypy from a different directory than the file I want to check is in.

I will note that I am running mypy from a virtual environment (venv), and it was installed correctly there (so technically, I used sudo chmod -R go+rX ~/venv/cliff/lib/mypy when I tried to do the fix from #389)

I also will note that I am using it with Python 3.5.1.

[gvanrossum]

How did you install mypy from the git clone?

[xlorepdarkhelm]

pip3 install mypy-master.zip

I can't just pull from github, the system I am installing on has no access to the internet.

[gvanrossum]

Hm, I'm not familiar with instructions that tell you to do that. This
is what works for me (in the repo):

git submodule update typeshed
pip3 install -U .

You may also be able to do what the README says (if you don't want a clone):

pip3 install git+git://github.com/python/mypy.git

(I'd still add -U since you've already installed it once. :-)

[xlorepdarkhelm]

I just tried it with the released 0.3.1 tarball, with exactly the same results.

I can't clone it to the system I am trying to install to, because that system is behind a firewall preventing internet access. As such, I need a package I can transfer to it and install. My workstation also is behind a firewall preventing pip3 from using my network connection. I can use my web browser to get the files, and then pip3 to install the files I downloaded. Yes, this is a bit of a hassle.

The usual method I use to get libraries from PyPI is: Downbload the source tarball, and then SFTP it to the dev server, then pip3 install it there. I tried that with mypy-0.3.1.tar.gz from PyPI (https://pypi.python.org/pypi/mypy-lang). I am getting the same results as I explained above. This is essentially the same as pip3 install mypy-lang when there isn't a firewall blocking it.

(cliff) user@lserver:~/venv/cliff/nrpe/pampas-py> pip3 install -U mypy-0.3.1.tar.gz
Processing ./mypy-0.3.1.tar.gz
Building wheels for collected packages: mypy-lang
  Running setup.py bdist_wheel for mypy-lang
  Stored in directory: /path/to/home/.cache/pip/wheels/9c/39/f9/b809b5b5f41e1d772521fe3dee1a2cf7e634e9feb7c2fb69d1
Successfully built mypy-lang
Installing collected packages: mypy-lang
  Found existing installation: mypy-lang 0.3.1
    Uninstalling mypy-lang-0.3.1:
      Successfully uninstalled mypy-lang-0.3.1
Successfully installed mypy-lang-0.3.1
(cliff) user@server:~/venv/cliff/nrpe/pampas-py> mypy pampas/core/common.py
pampas/__init__.py:1: error: Could not find builtins
(cliff) user@server:~/venv/cliff/nrpe/pampas-py> cd pampas/core
(cliff) user@server:~/venv/cliff/nrpe/pampas-py/pampas/core> mypy common.py
common.py: note: In class "Plugin":
common.py:1318: error: Parse error before "async"
common.py:1318: error: Parse error before :
common.py:1319: error: Inconsistent indentation
common.py: note: At top level:
common.py:1751: error: Inconsistent indentation
common.py: note: In class "ListEntryGenerator":
common.py:2423: error: Parse error before "def"
common.py:2423: error: Parse error before :
common.py:2424: error: Inconsistent indentation
common.py:2425: error: Parse error before "self"
common.py: note: At top level:
common.py:2428: error: Parse error before "def"
common.py:2428: error: Parse error before :
common.py:2429: error: Inconsistent indentation
common.py:2437: error: Parse error before "task"
common.py:2442: error: Inconsistent indentation
common.py: note: In class "ListEntry":
common.py:2776: error: Parse error before "async"
common.py:2776: error: Parse error before :
common.py:2777: error: Inconsistent indentation
common.py:2793: error: Parse error before "loop"
common.py: note: At top level:
common.py:2909: error: Parse error before "async"
common.py:2909: error: Parse error before :
common.py:2910: error: Inconsistent indentation
common.py:2922: error: Parse error before "loop"
common.py:2924: error: Inconsistent indentation
common.py:3041: error: Parse error before "async"
common.py:3041: error: Parse error before :
common.py:3042: error: Inconsistent indentation
common.py:3052: error: Parse error before "cls"
common.py:3052: error: Parse error before :
common.py:3053: error: Inconsistent indentation
common.py:3055: error: Inconsistent indentation
common.py:3057: error: Inconsistent indentation
common.py:3057: error: Parse error before :
common.py:3058: error: Inconsistent indentation
common.py:3076: error: Inconsistent indentation
(cliff) user@server:~/venv/cliff/nrpe/pampas-py/pampas/core>

[xlorepdarkhelm]

You'll notice I am getting the same error as in #285 when it works. But I want it to actually get to that point without needing to change directory.

[gvanrossum]

Parse errors are reported before it even tries to look for builtins, so it's not so surprising that if there are parse errors (for whatever reason) you don't get the complaint about builtins. The parse error you seem to get is because mypy doesn't yet support the async/await keywords added in Python 3.5. We're working on that (possibly through the experimental option --fast-parser, which exists in the repo but not in the 0.3.1 release; it depends on https://github.com/ddfisher/typed_ast). I see nothing wrong with the tarball. Maybe you could try unpacking it and using `python3 setup.py install`? The reason it can't find builtins is usually that the typeshed files are installed (by pip) in a place where mypy can't find them (because it doesn't know the full algorithm that pip uses). You could try to figure out where pip installs them and compare it to the code in build.py that looks for them -- print the value of lib_path after it's been computed (just before the call to the `BuildManager(...)` constructor in `build()`). I'm sorry your setup is so broken (through no fault of your own) and it's commendable that you're trying to work around it!

[xlorepdarkhelm]

Thanks, hopefully I can figure out what is needed. I'll look into finding out where the typeshed files are located.

My setup is broken because my employer is very particular about their security, and there is a mile-high stack of bureaucracy to go through in order to be able to open access to PyPI directly, and it just isn't worth the effort, especially as the software I am working on is time-critical for my employer and I can't really afford to waste time getting through the red tape, I just find creative alternatives (like building the entire Python 3.5.1 system, along with all of the SciPy stack from scratch, which also included building a more modern version of GCC -- this is not something I recommend for anyone to do).

mypy looks like such a useful tool, once I can get it worked out. Bummer about the async/await limitation, as I've been migrating my code over to using asynchronous coroutines more and more. Hopefully mypy will support it soon.

[PAStheLoD]

I think you are missing the /usr/local/lib/mypy/typeshed directory. (If you run pip3 as root.) Because using pip install git+... does a recursive clone, so you get the typeshed submodule. But github's ZIPball method doesn't include that.

I think the best way for this is to do the git clone --recursive yourself, and ZIP that (optionally delete the .git folder and .git* files) and pip install that.

[gvanrossum]

But the OP wrote

I tried that with mypy-0.3.1.tar.gz from PyPI (https://pypi.python.org/pypi/mypy-lang). I am getting the same results as I explained above.

That tarball (https://pypi.python.org/packages/source/m/mypy-lang/mypy-lang-0.3.1.tar.gz) does contain the typeshed tree.

[PAStheLoD]

Ooops, sorry, I saw the pip install mypy-master.zip comment and haven't noticed the mention of the PyPI tarball!

Then OP probably needs to do some strace-ing. (strace -f mypy -c 'def f(i: int) -> None: return 5' |& grep typeshed would show exactly where mypy is looking for the stubs.) Also pip3 uninstall mypy-lang will show the files known to pip, which would show the typeshed files if they are indeed present.

[gvanrossum]

Any news? If we don't hear from @xlorepdarkhelm by May 13 I will close this issue as irreproducible.