New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add stubs for nanoleafapi #11619
base: main
Are you sure you want to change the base?
add stubs for nanoleafapi #11619
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mostly looks great (though I haven't finished reviewing it), but I'm concerned that the upstream repository already looks like it has nearly 100% type coverage. Have you considered filing an issue upstream asking them if they would consider adding a py.typed
file? If they would, then there'd be no need for us to add third-party stubs here.
Admittedly, it doesn't look like there's been any activity in the upstream repo for two years, so if they're nto responsive we can absolutely add stubs here. But it would be good to check that first, I think :-)
This comment has been minimized.
This comment has been minimized.
Thank you very much for checking! Good point, I'll create an issue with the upstream repository :) |
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Busy week, but I just created the issue here. I'll post an update here if hear from the author! Also, if you don't mind, I have an additional question @AlexWaygood : In one of your commits, you removed a line with a reference to the |
Adding the entry in the pyrightconfig file means that pyright will only test this directory of stubs with our "baseline" pyright settings, rather than our stricter pyright config that enforces (for example) all parameters having annotations. Most people when they use our |
I added stubs for nanoleafapi (see on PyPi and on Github. I generated the stubs as indicated in the contribution guide, and then clarified some types.
Incomplete
is still used a few times in the API, e.g. innanoleaf.pyi
In those cases, the
nanoleafapi
project itself makes no assumptions on the exact types that are returned from the API, but passes them on to the client code. One could probably make this more specific by studying Nanoleafs API documentation, however in that case the stubs could become wrong when Nanoleaf changes their API - that's why I believe it makes sense to just use Incomoplete here.