How do you feel about hosting third party stubs for uWSGI?

[Daverball]

uWSGI is a bit of a weird package, since it is very low level and mostly written in C and the exported python packages for intereacting with uWSGI do not exist at runtime, unless the python application is started using uWSGI. So by default stubgen, and more importantly stubtest will not work, unless they are also run inside a uWSGI process.

For stubgen/stubdefaulter that's not as big of a deal, since by hacking together a new wsgi script I can run either of them inside uWSGI and get baseline stubs for uwsgi (Although they don't include uwsgi.decorators for some reason, but since that module is written in pure Python it should be easy to generate from source directly, it's also a lot more well-documented than the low level API). But if we wanted to run stubtest we would also need a hacky workaround there and I haven't checked yet if stubtest would work on uwsgi.decorators.

So I'm trying to get an idea for how much willingness there is to take on either additional technical debt, by special casing uWSGI in stubtest or risk less maintainable stubs by skipping stubtest for uWSGI altogether.

[Akuli]

The gdb stubs have the same situation, so I think this will be fine. There's discussion about the gdb stubs on python/typeshed#8013.

[Daverball]

Thanks, I'll have a look at the discussion.
Maybe I can get some more opinions on this from some of the other lovely typeshed people: @AlexWaygood @JelleZijlstra @srittau

[AlexWaygood]

+1 to everything Akuli said :)

It's extremely useful to run stubtest wherever possible, but it's not run on all our stubs, and the stubtestability of a stubs package shouldn't be a determining factor on whether we accept them to typeshed

[JelleZijlstra]

It depends a littl on what "you" means here :)

As a typeshed maintainer, I agree with @Akuli and @AlexWaygood that we'd be happy to host these stubs in typeshed if they'd be useful for the community.

As a maintainer of mypy (and therefore stubtest), I'm a little more wary. I'd be open to accepting a change to stubtest to allow testing this package if it's not too invasive and doesn't cause too much future maintenance burden, but I'd have to see the change first.

[Daverball]

Alright great. I think I will just start by creating a hacky script to run stubtest inside uWSGI locally to gauge whether or not that is even enough to get useful feedback. stubgen already couldn't figure out the signature for all the functions, so it's likely stubtest wouldn't provide anything useful beyond the "does everything that is supposed to exist at runtime also exist inside the stubs" checks and vice versa.