Remove redis (not before February 2025)

[srittau]

---

Deferred: As of redis-py 5.0.3 the upstream annotations are lacking. We should not remove these stubs, until the upstream annotations reach parity with the stubs.

[srittau]

Redis 5.0.0 added a py.typed file. Still, I wonder whether we should remove our stubs at this point, as the redis code is basically untyped, even quite fundamental classes and methods.

[AlexWaygood]

Yes, I'm pretty unsure what the best course of action is for our users here.

On the one hand, we generally remove stubs as soon as a library adds a py.typed file. I think that's the correct general policy: if a library's maintainers want to declare their inline types good enough for public consumption, then we should probably defer to them on that.

On the other hand, from the conversation in redis/redis-py#2738, it sounds like the redis maintainers acknowledge that their typing is pretty incomplete.

On the third hand, it also sounds from the conversation in redis/redis-py#2738 like they're unhappy with the quality of our stubs, and would prefer to provide their own type hints if possible.

I suppose the ideal situation would be if we contributed as many as possible of our types in typeshed to redis. But without knowing where the errors referenced in redis/redis-py#2738 (comment) are, it's hard to know where these would be welcome and where they wouldn't be.

[Avasam]

@AlexWaygood typeshed recently supports creating partial stubs on purpose. Exactly with cases like this in mind. It's something that is likely to happen eventually in pywin32 as well.

We can mark the stub as partial, but NOT stubtest incomplete. Then ignore known typed modules (with a comment) in stubtest-allowlist.
As more modules get typed in Redis, we can remove modules from types-Redis and keep bumping the version pin.

Type tests will of course need the base library to be installed (can't remember if they already do that. Pyright?)
Idk if it'll need a stubsabot update to prevent re-openning an issue.

[AlexWaygood]

Oh, so if we mark the stubs as partial, type checkers will only look at the annotations for the submodules we include in typeshed, and fall back to inline types in the runtime package for the submodules we don't include? (I'm not too familiar with the details of PEP-561!)

[Avasam]

This is the specification for partial stubs as per https://peps.python.org/pep-0561/#partial-stub-packages

[...] modules not found in the stub package SHOULD be searched for in parts four and five of the module resolution order above, namely inline packages and typeshed.

Type checkers should merge the stub package and runtime package or typeshed directories. This can be thought of as the functional equivalent of copying the stub package into the same directory as the corresponding runtime package [...]

Pyright's documentation about order resolution is relevant here as well: https://microsoft.github.io/pyright/#/import-resolution?id=resolution-order

[meshantz]

Since there are so many upstream issues yet to be resolve, can we remove the recommendation to remove types-redis mentioned on the package page https://pypi.org/project/types-redis/:

Note: The redis package includes type annotations or type stubs since version 5.0.0. Please uninstall the types-redis package if you use this or a newer version.

Or if you don't want it removed, at least add some caveats?

[srittau]

@meshantz Thanks for the suggestion. We now removed the wording and instead suggest du leave the package installed for now.

[Avasam]

Note that typeshed-internal/stub_uploader#108 will probably need to be fixed first to properly support partial type stubs for Redis.