elahd/ha-nyc311

Integration is using deprecated `DEVICE_CLASS_*` constants

frenck opened this issue · 6 comments

This custom integration uses deprecated DEVICE_CLASS_* constants in its codebase.

The DEVICE_CLASS_* constants have been deprecated and replaced in Home Assistant Core 2021.12 (over a year ago). I would highly suggest updating/migrating this integration to the new enums.

For example, for the device classes supported by the sensor platform, there is now a SensorDeviceClass enum. So if a sensor previously used the DEVICE_CLASS_ENERGY constant, it should now use SensorDeviceClass.ENERGY. Other platforms (like binary_sensor, and number) provide similar enumerations for their supported device classes.

The migration thus only consists of replacing constants with an enumeration member and is, therefore, very low impact and should be fairly straightforward.

If I can help resolve any questions regarding this change or migration, feel free to ask or respond to this issue. I'm happy to help!

Kindest regards,

../Frenck

elahd commented

Thanks, @frenck, but this is a false positive. I import Home Assistant's pylint/plugins directory into my integrations. It looks like you're picking up DEVICE_CLASS_ keywords in those files.

Oh I see @elahd 👍

Sorry for the noise! Interesting to see it is being vendorized though 🤔
It makes me wonder if we should just publish it separately as an installable plugin on PyPI or something.

Anyways, Happy New Year!

../Frenck

elahd commented

@frenck That would be awesome.

I'm using ludeeus' integration devcontainer with a custom post set version hook. Every time the devcontainer's "Set Home Assistant Version" task is called, my post set version script pulls the source code for that version of Home Assistant and copies its pylint/plugins directory into the integration's root.

It's a Rube Goldberg machine. Would be much easier to just pull a pypi library for a specific version of home assistant.

Happy New Year!

elahd commented

@frenck For what it's worth, I have a similarly crazy build process for running hassfest locally. It would be great for that to be available independently, as well!

@elahd Hassfest can be run using a container, similar to how we run it as a GitHub Action.
Hassfest itself depends on Home Assistant Core to function.

elahd commented

@frenck Yeah -- the challenge is running a docker container from within a devcontainer. I may have missed an easier approach to this, but what I settled on is just using the Home Assistant source code that I pull for the pylint plugins with another custom script.

I did just find these instructions explaining how to spin up multiple devcontainers for a single project. I can play around with that to see if there's an easy way to trigger a hassfest run via docker from within a devcontainer. I'll post back here if I make any progress. May be a useful follow up to Hassfest for custom components.