We've agreed that we're not introducing the type hinting in the code now. Does it make sense to include independent stubs in the codebase? (extended version of https://github.com/obriencj/koji-smoky-dingo/blob/master/stubs/koji/) @mikem?
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue set to the milestone: 1.34
Metadata Update from @tkopecek: - Issue set to the milestone: 1.33.1 (was: 1.34)
Metadata Update from @tkopecek: - Issue untagged with: discussion - Issue tagged with: no_qe
Metadata Update from @tkopecek: - Issue set to the milestone: 1.34 (was: 1.33.1)
Metadata Update from @tkopecek: - Issue set to the milestone: 1.35 (was: 1.34)
Just an update, I shifted the organization of the typing stubs around recently. They're now under https://github.com/obriencj/koji-smoky-dingo/tree/master/mypy
There's also a custom mypy plugin in use now to assist in the difficult case of the MultiCallSession. It's possible to implement a full set of methods on MultiCallSession without the plugin, but you'll have to copy/paste every single method from ClientSession and then update the return types to be the VirtualCall wrapper.
If koji team ever decided that it was not going to deliver the stubs directly in the koji wheel itself, there's a possibility for an auxiliary wheel to deliver them, so long as it provided a package named "koji-stubs"
https://peps.python.org/pep-0561/#stub-only-packages
Metadata Update from @tkopecek: - Issue set to the milestone: 1.36 (was: 1.35)
Let's drop this and see where the external solution goes
Metadata Update from @tkopecek: - Issue close_status updated to: Dropped - Issue status updated to: Closed (was: Open)
Metadata Update from @tkopecek: - Issue set to the milestone: None (was: 1.36)
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji/issues/3708
Please continue any further discussion there.