Inconsistent .mypy_cache for PyJWT library

[surkova]

Bug Report

.mypy_cache files for PyJWT library are different in a CI docker container and locally.

To Reproduce

Mypy check fails on the following line in the CI container:

import jwt

def generate_auth() -> str:
    return jwt.encode({}, "secret_string", algorithm="HS384")

with Incompatible return value type (got "bytes", expected "str") (line 4).

I am not able to completely reproduce container setup, since it's done by our corporate internal tooling.

Expected Behavior

Cache files are generated consistently regardless env setup. I'm perplexed about why this could be happening since it's not even my project code, but an external library. And it's failing because of the lack of some stubs (api_jwk, api_jws etc).

Actual Behavior

docker:

appuser@e162eb7118cd:~$ ls .mypy_cache/3.8/jwt/
algorithms.data.json  algorithms.deps.json  algorithms.meta.json  __init__.data.json    __init__.deps.json    __init__.meta.json

locally:

➜  git:(dependabot/pip/pyjwt-2.0.1) ls .mypy_cache/3.8/jwt
__init__.data.json    algorithms.meta.json  api_jws.data.json     api_jwt.meta.json     jwks_client.data.json utils.meta.json
__init__.meta.json    api_jwk.data.json     api_jws.meta.json     exceptions.data.json  jwks_client.meta.json
algorithms.data.json  api_jwk.meta.json     api_jwt.data.json     exceptions.meta.json  utils.data.json

Your Environment

• Mypy version used: 0.812
• Mypy command-line flags: --ignore-missing-imports (but I tried with no flags, just -v for verbose output)
• Mypy configuration options from mypy.ini (and other config files): no config file
• Python version used: 3.8.7
• Operating system and version: macOS BigSur 11.2.2 (20D80) (locally), Ubuntu 18.04.5 LTS

[JukkaL]

Do you have PyJWT installed in the environment where you mypy? If yes, do you have the same version of PyJWT installed in both environments?

[surkova]

@JukkaL yes, PyJWT is installed in both environments. I discovered this issue in the dependabot branch which upgrades the version from 1.7.1 to 2.0.1 and when bumping to 2.0.0 PyJWT added typing annotations and changed the type which jwt.encode returns. Now without the stubs, for some reason, mypy thinks that that method still returns bytes, not str.

[surkova]

@JukkaL any news regarding this?

[surkova]

I did further digging and it turns out the discrepancies between files are caused by typeshed:

python/typeshed@67a2ed7

For some reason on CI typeshed is used while locally the cache is being generated by py.typed annotation

[srittau]

Some ideas of what could you wrong in CI:

• A pre-2 version of PyJWT get installed and is used.
• An old .mypy_cache directory is not cleaned correctly.
• PyJWT is installed incorrectly, and the py.typed file is missing.

Maybe upgrading to mypy 0.901 will help as that doesn't ship third-party packages, so there should be no way for CI to pick up the stubs, unless the types-PyJWT (or the misnamed types-jwt) package is also installed. (Which it shouldn't when using PyJWT 2+.)

[surkova]

Thanks for checking this out!

I have tried upgrading now and discovered a different problem: I installed types for 3rd parties as requested and everything runs smoothly, but I cannot convince mypy to see those types, not sure which directory it looks in. In docker container my dependencies are installed under /artifacts/pip:

...
mypy==0.901
...
types-cryptography==0.1.2
types-dateparser==0.1.2
types-enum34==0.1.5
types-freezegun==0.1.2
types-ipaddress==0.1.2
types-jwt==0.1.3
types-pkg-resources==0.1.2
types-python-dateutil==0.1.2
typing-extensions==3.10.0.0

I get errors like Library stubs not installed for "jwt" (or incompatible with Python 3.8)

[JukkaL]

Can you give the output of this fragment from your container:

import site
print(site.getusersitepackages())
print(site.getsitepackages())

Mypy looks for installed stub packages in these directories.

[surkova]

@JukkaL

appuser@835d6bea133e:~$ python
Python 3.8.8 (default, May 31 2021, 07:26:03)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> print(site.getusersitepackages())
/app/.local/lib/python3.8/site-packages
>>> print(site.getsitepackages())
['/usr/local/lib/python3.8/site-packages']
>>>
appuser@835d6bea133e:~$ ls /app/.local/lib/python3.8/site-packages
appuser@835d6bea133e:~$ ls /usr/local/lib/python3.8/site-packages
easy_install.py  pip  pip-20.2.3.dist-info  pkg_resources  __pycache__	README.txt  setuptools	setuptools-49.2.1.dist-info

Also

appuser@835d6bea133e:~$ python -m site
sys.path = [
    '/app',
    '/artifacts/pip',
    '/usr/local/lib/python38.zip',
    '/usr/local/lib/python3.8',
    '/usr/local/lib/python3.8/lib-dynload',
    '/app/.local/lib/python3.8/site-packages',
    '/usr/local/lib/python3.8/site-packages',
]
USER_BASE: '/app/.local' (exists)
USER_SITE: '/app/.local/lib/python3.8/site-packages' (exists)
ENABLE_USER_SITE: True

[pranavrajpal]

It looks like the problem is that you're installing to /artifacts/pip instead of either site-packages directory, which makes this the same issue as #5701.

[abhinavsingh]

For posterity, just wanted to point out, in our scenario --show-stacktrace revealed that the problem was elsewhere (with Django settings resolution), but from logs it seemed like a mypy issue.

[hauntsaninja]

Closing, since there isn't a clear repro, and several things have changed that could potentially have fixed this