The root cause is that the

mypy_django_plugin

needs to load the Django models at the start, which it cannot do without the dependencies installed in the

mypy

virtual environment. Adding

celery

to

extra_requirements

under

[mypy]

in

pants.toml

removes this error, but this seems to be a hack. In my actual repo, I would need to add around fifty requirements here, which would be difficult to maintain.

This is annoying - we make the 3rdparty requirements available to mypy using the

--python-executable

flag to point it to a venv that has them installed. But the django-stubs mypy plugin doesn’t lean on that setting, it looks like. It just expects the django code to be loadable in the interpreter in which it was run

@hundreds-father-404 any thoughts on this?

[I’m about to go on vacation, so I am punting this to Eric, who is the expert on this anyway]

Note that if, in the sandbox, I set

PEX_EXTRA_SYS_PATH=.cache/pex_root/venvs/789d932fffbc7a5f62a53225281080e2a0a691f3/aa6b67e0280d525b74426f4efccdd3affff905bd/lib/python3.7/site-packages/

then the mypy invocation works

So maybe we create an escape hatch to let you opt in to running mypy with the requirements pex available in this way?