Support third-party stub external dependencies in pytype

[Avasam]

Work towards #5768
Based on, and mostly a copy of what's done in, #9434 (hence I'm keeping this as draft until the pyright PR is merged)

I'll revert the demo changes in METADATA.toml after the above is merged.

The pytype failure seen in #9374 seems to be caused by non-typed external dependencies, which we decided we won't support at the moment anyway.

[Avasam]

I changed the wording here because since #9382, test/utils.py (which is used by all tests) uses functools.cache, which is unavailable in Python 3.8.

[AlexWaygood]

In practice we've required 3.9+ for a lot longer, due to the use of ast.unparse in tests/check_new_syntax.py :)

[Avasam]

Good to know. I believe you could still run other tests, so "recommend" wasn't too inaccurate :P

I only noticed because I had 3.8 installed in WSL.

[Avasam]

Same wording as before, just added "pytype_test and" moved it up to avoid duplicating this entire paragraph.

[Avasam]

Successful pytype run: https://github.com/python/typeshed/actions/runs/3833991938/jobs/6525955844

[AlexWaygood]

Looks good, thanks! Some very minor points below

[AlexWaygood]

@rchen152, I'd love your opinion on this as a pytype maintainer, if you've the time.

We're trying to rework our test suite to allow our third-party stubs packages to have dependencies on non-stubs packages external to typeshed which ship with py.typed files. For mypy_test.py, my proposed approach in #9408 is to dynamically create virtual environments in order to test each stubs package in isolation. For pyright, however, we went with #9434, which simply installs all dependencies for all third-party stubs into one environment before testing them all together.

The pyright approach has the advantage that the test code is much simpler and faster, but could lead to false negatives. If you add import numpy in a stubs package, but forget to declare a dependency on numpy for that package, pyright might not emit an error due to numpy already being installed for some other stubs package that we're testing. The mypy approach doesn't suffer from this flaw.

We could probably go either way when it comes to running pytype in CI — the "simple" approach we're using for pyright, or the "somewhat more principled" approach I'm proposing for mypy. The proposal in this PR is to use the pyright approach. Do you have any preference at all?

[AlexWaygood]

LGTM, but I'll wait a little bit to see if the pytype maintainers have any thoughts before merging :)

[rchen152]

Thanks for looping me in! This change looks good to me =) If mypy is already testing each package in isolation, it seems reasonable to use the "simple" approach for pytype.

[AlexWaygood]

Brilliant, thanks for taking a look!