You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Work on merging annotations from types-pika (a non-typeshed project) into typeshed's pika stubs #9246
It's too bad there aren't protected namespaces on PyPI. I suggest we add a field packagedistribution or similar to METADATA.toml where we can put an alternative distribution name if necessary.
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).
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!
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.
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, 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?
This takes the pressure off, giving us more time to work on consolidating stubs for pika without worrying about the stub uploader constantly failing :)
changed the title [-]Automated stub uploader constantly failing because types-pika already exists on PyPI[/-][+]pika stubs cannot be uploaded to PyPI: types-pika already exists[/+]on Nov 24, 2022
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.
changed the title [-]pika stubs cannot be uploaded to PyPI: types-pika already exists[/-][+]Work on merging annotations from types-pika (a non-typeshed project management ) into typeshed's pika stubs[/+]on Dec 15, 2022
changed the title [-]Work on merging annotations from types-pika (a non-typeshed project management ) into typeshed's pika stubs[/-][+]Work on merging annotations from types-pika (a non-typeshed project) into typeshed's pika stubs[/+]on Dec 15, 2022
With the recent changes, I think the effort to merge the type annotations is effectively complete. At this point, baodrate/types-pika no longer seems to offer any clear advantages over the typeshed stubs, especially in terms of maintenance.
It might be worth considering transferring the PyPI package name, or adding a note directing users to the typeshed stubs as the recommended option.
I saw the pika project adding type hints to itself: pika/pika#1529
Yes, you're right. pika has indeed added type annotations, and more importantly, a py.typed file (pika/pika#1632). However, the release containing the py.typed file is planned for the next minor version (1.5.0). The current releases still don't include py.typed so the package isn't considered typed yet.
Activity
srittau commentedon Nov 22, 2022
It's too bad there aren't protected namespaces on PyPI. I suggest we add a field
packagedistributionor similar toMETADATA.tomlwhere we can put an alternative distribution name if necessary.AlexWaygood commentedon Nov 22, 2022
Is it worth temporarily removing the stubs from typeshed for now, as a stopgap measure?
ilevkivskyi commentedon Nov 22, 2022
Btw
mypy(and I guess other tools too) will automatically propose to installtypes-xxx(if types forxxxare 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 commentedon Nov 22, 2022
I think mypy has a whitelist of "known" type packages to prevent just such a scenario.
Support a "stub_distribution" metadata field
srittau commentedon Nov 22, 2022
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 commentedon Nov 22, 2022
Happy to do whatever is needed to resolve this. Sorry for stepping on your namesake in the first place
AlexWaygood commentedon Nov 22, 2022
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 commentedon Nov 22, 2022
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 commentedon Nov 22, 2022
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 commentedon Nov 22, 2022
Yes, that would be perfect! Thank you!
Disable pika uploads for now
Disable pika uploads for now (#9257)
AlexWaygood commentedon Nov 24, 2022
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 :)
[-]Automated stub uploader constantly failing because types-pika already exists on PyPI[/-][+]pika stubs cannot be uploaded to PyPI: types-pika already exists[/+]Distribute our pika stubs under an alternate name
Distribute our pika stubs under an alternate name
Distribute our pika stubs under an alternate name (#9358)
AlexWaygood commentedon Dec 15, 2022
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.[-]pika stubs cannot be uploaded to PyPI: types-pika already exists[/-][+]Work on merging annotations from types-pika (a non-typeshed project management ) into typeshed's pika stubs[/+][-]Work on merging annotations from types-pika (a non-typeshed project management ) into typeshed's pika stubs[/-][+]Work on merging annotations from types-pika (a non-typeshed project) into typeshed's pika stubs[/+]donbarbos commentedon Jul 24, 2026
With the recent changes, I think the effort to merge the type annotations is effectively complete. At this point, baodrate/types-pika no longer seems to offer any clear advantages over the typeshed stubs, especially in terms of maintenance.
It might be worth considering transferring the PyPI package name, or adding a note directing users to the typeshed stubs as the recommended option.
cc @baodrate
LincolnPuzey commentedon Jul 27, 2026
I saw the pika project adding type hints to itself: pika/pika#1529
Not sure what impact that has here
donbarbos commentedon Jul 27, 2026
Yes, you're right.
pikahas indeed added type annotations, and more importantly, apy.typedfile (pika/pika#1632). However, the release containing thepy.typedfile is planned for the next minor version (1.5.0). The current releases still don't includepy.typedso the package isn't considered typed yet.