Mark homeassistant PEP 561 compatible

[elupus]

Description:

Mark homeassistant package as pep 561 compatible https://www.python.org/dev/peps/pep-0561/. This allow custom components to run mypy checks on references to homeassistant components.

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[scop]

I don't think we can do this yet. PEP 561 says about the marker file:

if a top-level package includes it, all its sub-packages MUST support type checking as well.

A lot of our stuff isn't type checked at all yet, at least those parts I think don't qualify. And a lot have inline mypy exclusions, I suppose those don't qualify either.

https://www.python.org/dev/peps/pep-0561/#packaging-type-information

[elupus]

We run mypy internally on all of home assistant. So at least it doesn't fail.
Also home assistant isn't really a lib per say. So this is mostly for custom components, so if it is somewhat incomplete I don't think it matters too much. I don't think anything could get worse by this?

I'm not too vested in this though.

[scop]

I'm fairly certain (but haven't tested) that if we mark ourselves as typed but we actually are not typed everywhere, things will get noticeably worse for custom components and other "external" users that happen to use the parts that are not type hinted.

An example: ruamel.yaml does exactly this, marks itself as PEP 561 compatible but lacks severely in type hints. Because of that we have to add some # type: ignores to get mypy checks to pass when ruamel.yaml is installed, but that will cause errors when it isn't (because we're running with warn_unused_configs on and that's a good default to keep codebase clean of unnecessary type ignores). And further because of this we have several mypy pre-commit configurations. So it's definitely worse. See https://bitbucket.org/ruamel/yaml/pull-requests/42

[scop]

So at the minimum I'd say someone needs to test how type checks behave if we have that marker, and an external thing uses some of our untyped functionality and runs type checks with the same strict config as we do. The original report says the change is tested, but is it tested against this use case?

[elupus]

It's just tested against my custom component. It is not set especially strict thought.

[elupus]

The problem is that mypy complains whenever home assistant component are imported that it can't be found. since it consider the lib untyped. So it reduced warnings by about 30 in the custom component.

[scop]

Is your component using any of our untyped functions?

[elupus]

I'm unsure. The component isn't fully typed either. https://github.com/elupus/hass_nibe

I will try to do some more verification.

[springstan]

@elupus any updates on this PR? :)

[elupus]

Sorry no. Not had time to look at it.

[springstan]

No worries, I was just curious.

[stale]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.