unixorn / ha-mqtt-discoverable

Python module to create MQTT entities that are automatically discovered by Home Assistant
Apache License 2.0
95 stars 22 forks source link

Bump pydantic version to ^2.0.0 #191

Closed mmaeusezahl closed 4 months ago

mmaeusezahl commented 6 months ago

The issue https://github.com/unixorn/ha-mqtt-discoverable/issues/175 also bit me. Luckily bumping the version did not seem too hard. This PR would solve dependabots https://github.com/unixorn/ha-mqtt-discoverable/pull/188.

Type of changes

Checklist

snicker commented 4 months ago

just want to point out that versions of Pydantic > 2.0.0 have added a lot of really wild system level requirements and has made doing things on 32 bit ARM platforms like the RPI zero really difficult- I am having to manually downgrade to a version of ha-mqtt-discoverable to avoid moving to pydantic 2. I know type safety is cool and all, but them moving to a pure C implementation has made relying on it unnecessarily burdensome and adds a ton of bloat to libraries using it.

snicker commented 4 months ago

to clarify things that I had to do:

  1. pydantic >2 cannot be built on 32bit arm architectures
  2. downgrade from python 3.12 to 3.11 because there is a prebuilt wheel for pydantic on piwheels.com
  3. glibc 2.33 is required for pydantic-core >2, though most rpi distros of debian will not have this- i'm in the midst of building 2.33 to run on this device
  4. I am anticipating # 3 to not work

I use ha-mqtt-discoverable on edge devices that don't need to be powerful or running the latest OS - pydantic core has taken a strange approach in v2 and not added numerous benefits. Understanding your use case here @unixorn - dealing with a conflict - but I'm going to have to pin to ha-mqtt-discoverable to 0.13.1

mmaeusezahl commented 4 months ago

Hi,

sorry to hear that my PR lead to such digressions (I got a notification as the author).

Usually I'm all in favor of updating to the most recent dependencies, but for this particular package I understand why broad support across weak/old hardware is useful. I myself might want to target ARM 32bit architectures.

Yet I don't really understand why this issue even appears. Shouldn't pip automatically dismiss ha-mqtt-discoverable 0.13.1 if it can't fulfill the requirements and choose an older version? Like: What specific package did you try to install?

I think that pinning a specific version in a downstream package is the wrong step as it just relocates the problem.

In this case, there might be an ad-hoc, "easy to maintain" solution to support both pydantic v1 and v2 by using the pydantic.v1 module https://docs.pydantic.dev/latest/migration/#continue-using-pydantic-v1-features. I am thinking something like

#### Untested!
try:
   import pydantic.v1 as pydantic_v1
except:
   import pydantic as pydantic_v1

I did purposely not choose this path (using the new API instead of the the pydantic.v1 compatibility layer) in my PR since I wanted to prevent accumulation of technical debt. But I guess under these specific circumstance I might be a temporary fix for ha-mqtt-discoverable to allow both pydantic v1 and pydantic v2.

Imo, in the long run this should be treated differently. I imagine:

Yet both will probably require major work.

unixorn commented 4 months ago

I like the idea of using the same validator as HASS. I don't really have time rn to work on this, but I'm happy to accept more PRs.

I'll add the 0.13.1 pin to the readme.