search

python / typeshed

Collection of library stubs for Python, with static types
Other
4.3k stars 1.73k forks source link

Work on merging annotations from types-pika (a non-typeshed project) into typeshed's pika stubs #9246

Open ilevkivskyi opened 1 year ago

ilevkivskyi commented 1 year ago

See for example https://github.com/typeshed-internal/stub_uploader/actions/runs/3521987995/jobs/5904439698

PyPI: https://pypi.org/project/types-pika/ Ref https://github.com/python/typeshed/pull/9200

cc @srittau @JelleZijlstra @qubidt

srittau commented 1 year ago

It's too bad there aren't protected namespaces on PyPI. I suggest we add a field package distribution or similar to METADATA.toml where we can put an alternative distribution name if necessary.

AlexWaygood commented 1 year ago

Is it worth temporarily removing the stubs from typeshed for now, as a stopgap measure?

ilevkivskyi commented 1 year ago

Btw mypy (and I guess other tools too) will automatically propose to install types-xxx (if types for xxx are missing). I guess we can discuss with the owner of the original package @qubidt how to "merge efforts"?

I would propose to revert that PR for now, so that automatic uploader will work. But this is probably not urgent, I guess people can wait a day or two without stub updates (or we can use manual upload action if something is urgently needed).

(also cc @JukkaL for visibility)

srittau commented 1 year ago

I think mypy has a whitelist of "known" type packages to prevent just such a scenario.

srittau commented 1 year ago

I've created a PR for the stub_uploader supporting a "stub_distribution" field if we decide to go that way: typeshed-internal/stub_uploader#76.

baodrate commented 1 year ago

Happy to do whatever is needed to resolve this. Sorry for stepping on your namesake in the first place

AlexWaygood commented 1 year ago

Happy to do whatever is needed to resolve this. Sorry for stepping on your namesake in the first place

I definitely don't think this is your fault, @qubidt :) I don't think there's any reason for typeshed to have any intrinsic "right" to types-* names on PyPI, it's just become an assumption around these parts that those names were available!

AlexWaygood commented 1 year ago

I do agree with @ilevkivskyi that we should work out how to collaborate, though, if that's something you'd be interested in @qubidt. It seems silly to have two different sets of stubs for pika.

It feels slightly unfair to ask, since you "got there first", but would you be interested in contributing your stubs to typeshed, @qubidt? It looks like you have a lot more "annotation coverage" than us at the moment over at https://github.com/qubidt/types-pika, but I think our CI checks are probably slightly more robust.

baodrate commented 1 year ago

yes, absolutely. although I'm not exactly how to proceed. should I try to merge the annotations from qubidt/types-pika into typeshed and create a PR for it?

AlexWaygood commented 1 year ago

yes, absolutely. although I'm not exactly how to proceed. should I try to merge the annotations from qubidt/types-pika into typeshed and create a PR for it?

Yes, that would be perfect! Thank you!

AlexWaygood commented 1 year ago

To update on the current status now: typeshed's automated stub uploader is now green again, due to the following trio of PRs by @srittau:

This takes the pressure off, giving us more time to work on consolidating stubs for pika without worrying about the stub uploader constantly failing :)

AlexWaygood commented 1 year ago

The stubs in typeshed are now uploaded to PyPI under the name types-pika-ts. But we should continue to work on merging annotations from types-pika into the typeshed stubs, so that end users can have the best experience possible.