Stub suggestions for non-typeshed stubs

[hauntsaninja]

Currently mypy only suggests installing stub packages if they're from typeshed. This restriction is important, because package installation can result in arbitrary code execution; potentially automatically when using --install-types.

However, we can loosen this a little bit. A concrete suggestion is to allow suggestions of stub packages that are under the same Github org as the actual package or maintained by the actual package maintainer. In particular, we've had a couple requests for lxml-stubs and pandas-stubs.

cc @JukkaL

[johnthagen]

As someone who only learned about pandas-stubs from this issue and had been using pandas for a long time, I think a big user experience would be to curate an additional list of "popular/trusted" third party stubs.

I would also want mypy to error out if it detected pandas was being used, but pandas-stubs was not installed, like it does for other typeshed packages

main.py:1: error: Library stubs not installed for "pandas"  [import]
main.py:1: note: Hint: "python3 -m pip install pandas-stubs"
main.py:1: note: (or run "mypy --install-types" to install all missing stub packages)
main.py:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 1 error in 1 file (checked 1 source file)

[twoertwein]

@hauntsaninja If pandas-stubs requires changes to be suggested by mypy, please let me and @Dr-Irv know. It would be great if pandas-stubs is more "aggressively" publicized :)

edit: One change might be to add a CI run with mypy nightly to pandas-stubs.

edit: Another change/test might be to run mypy_primer with pandas-stubs installed and then create issues at pandas-stubs for the reported failures

[johnthagen]

A good place for mypy to start would be to check out the stubs list on awesome-python-typing and perhaps select a conservative subset:

• https://github.com/typeddjango/awesome-python-typing#stub-packages

Also, @twoertwein, data-science-types is still listed there, so perhaps you could replace that with pandas-stubs?

[JukkaL]

It seems reasonable to loosen the rules a bit. Perhaps we'd want the stubs to be at least somewhat established, e.g. there would have to be commit activity over N months and we should be able to find some non-trivial projects that are using the stubs. PyPI download stats could also be used as a signal.

[JukkaL]

Another idea would be to first provide links to stub packages maintained outside typeshed in the mypy documentation, at least if we are unsure how mature the stubs are. We can then eventually promote stubs to be suggested by mypy if they seem to be sufficiently well-maintained and/or popular.