Skip to content

change requirements to pypi format, remove ESP32SPI requirement #15

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

Closed
wants to merge 6 commits into from

Conversation

Neradoc
Copy link

@Neradoc Neradoc commented Jul 13, 2022

While pypi doesn't care about - versus _ and letter case, the format used for the minimqtt requirement makes it listed in "external_dependencies" instead of "dependencies" in the bundle's json file, causing potential issues with bundler tools.
And the library does not need ESP32SPI, it works on native wifi too.

Copy link
Member

@tekktrik tekktrik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there's a CI error, but if same thing as the other PR - if any of the dependencies are used in optional functionalities or examples, could you add them to a new optional_requirements.txt? Thanks!

@Neradoc
Copy link
Author

Neradoc commented Jul 13, 2022

The error is from the docs run, because of the type annotations that use ESP32SPI. But if it works with native we don't want circup or others installing the ESP32SPI library. Projects that require the esp library will import it regardless of whether it's a requirement for LIFX or not.
So I added it back to setup.py.
I suppose that will be handed by the optional requirements in the future ?

@Neradoc Neradoc requested a review from tekktrik July 13, 2022 16:48
@Neradoc
Copy link
Author

Neradoc commented Jul 13, 2022

Also moved adafruit-circuitpython-esp-atcontrol to optional_requirements.txt

@tekktrik
Copy link
Member

tekktrik commented Jul 13, 2022

Trying to figure out how to type annotate something using type() without using said type is rough haha. Here's one solution with a few steps:

Add a type definition to adafruit_requests:

class WiFiManagerProtocol(Protocol):

    def post(url: str, **kwargs) -> Response:
        """Post method"""

    def put(url: str, **kwargs) -> Response:
        """Put method"""

    def get(url: str, **kwargs) -> Response:
        """Get method"""

        ...

Then, we can pull it in this library and modify it:

from typing import Union
from adafruit_requests import WiFiManagerProtocol, Session

ESP32SPI_WFM_Type = type("ESPSPI_WiFiManager", (), {})
ESPAT_WFM_Type = type("ESPAT_WiFiManager", (), {})

AllowedWiFiManagerProtocol(WiFiManagerProtocol):

    __class__: Union[Type[ESP32SPI_WFM_Type], Type[ESPAT_WFM_Type]]

AllowedWiFiManagerType = Union[AllowedWiFiManagerProtocol, Session]

I think AllowedWiFiManagerType is good then:

    def __init__(self, wifi_manager: AllowedWifiManagerType, lifx_token: str) -> None:

OOOORRRR we just remove the type annotation 😆 I'm open to that since the docstring is pretty clear

@Neradoc
Copy link
Author

Neradoc commented Jul 13, 2022

That's a lot of hoops to jump through to get to that !
I suppose there is something to be said about having a unified "network manager" type.

@tekktrik
Copy link
Member

The more I think about this more I think a general Protocol is useful, but not the code I had mentioned that was specific to this library. I think the docstring can just specify which specific classes that fit that mold are accepted. How does that sound? I can PR that change to circuitpython_typing if it sounds good.

@FoamyGuy
Copy link
Contributor

I can PR that change to circuitpython_typing if it sounds good.

This idea sounds good to me if you're still interested in PR'ing that in the typing library so it can be used here (and elsewhere as needed).

Mabye HTTPProtocol as a name? I think that is what defines all of those different types of requests.

@tekktrik
Copy link
Member

Definitely happy to do that!

@tekktrik
Copy link
Member

Okay, I'll make a new PR for the changes discussed here, but this looks good to me! I merged main into this so I can merge it :)

@tekktrik
Copy link
Member

Oh hey, it actually looks like the pyproject.toml migration fixed the issue, thanks y'all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants