Am 29.10.19 um 19:45 schrieb Brett Cannon:
So how would that work if you wanted to provide stubs for older project versions? Let's say for the deadparrot project there's types for version 40 (last version with Python 2 support) and version 42 (latest release), but those stubs are not compatible with each other (e.g. they went nuts with replacing string constants with enums in the latest release). How could stubs be provided for both versions simultaneously on typeshed without having to do a union solution of a single release that weakens the type details? On PyPI there's implicit version support so the stubs could be version-matched to the deadparrot project or be versions 1 and 2, but from what I can tell typeshed doesn't have a mechanism to provide two separate sets of stubs for the same project.
I had ideas for this, but I don't think I have written them down anywhere. At least I can't find it at the moment. But it basically comes down to restructuring the third_party directory in typeshed a bit: Instead of maintaining the current directory split by Python version, we'd have a flat hierarchy and each package sub-directory would contain a metadata file. (A first draft is actually at https://github.com/python/typeshed/blob/third-party-dist/third_party/build/M....) This could contain a package name and supported version range for the package. This would allow us to have, for example, third-party/foo-2 and third-party/foo-3 directories for different versions of the same package. Main problem is how the packages would be named on pypy. Ideally we'd use consistent names, so that type hints for a package "foo" are only a "pip install types.foo" away. But this would not work with supporting multiple package versions. - Sebastian