add stubs for nanoleafapi

[alexlukas]

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. in nanoleaf.pyi

    def write_effect(self, effect_dict: dict[str, Incomplete]) -> bool: ...
[...]
    def get_layout(self) -> dict[str, Incomplete]: ...

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.

[AlexWaygood]

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 :-)

[alexlukas]

Thank you very much for checking! Good point, I'll create an issue with the upstream repository :)

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[alexlukas]

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 stubs/nanoleafapi from pyrightconfig.stricter.json. I can't remember adding this here - I believe it might have happened when using the create_baseline_stubs.py helper script. What does the entry in the file mean, and in which cases would you create a new entry for a new stubs project?

[AlexWaygood]

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 stubs/nanoleafapi from pyrightconfig.stricter.json. I can't remember adding this here - I believe it might have happened when using the create_baseline_stubs.py helper script. What does the entry in the file mean, and in which cases would you create a new entry for a new stubs project?

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 create_baseline_stubs.py script still have at least some parameters unannotated, so it makes sense for the script to add new stubs directories to that excludelist by default. I noticed that these stubs were already fully annotated, however, so we can enable the stricter pyright settings in CI from the get-go :-)