developers.home-assistant icon indicating copy to clipboard operation
developers.home-assistant copied to clipboard

Integration manifest version conflicts

Open karmacop opened this issue 5 years ago • 5 comments

This is with regards to docs/creating_integration_manifest.md

What is the correct way to reference a required library that is already used within Home Assistant without causing a conflict? The current solution is to not reference a version number but that a) goes against the documentation and b) assumes versions maintain compatibility.

See https://github.com/sermayoral/ha-samsungtv-encrypted/issues/27

Scrape (a core part of HA) is using beautifulsoup4==4.9.0 ha-samsungtv-encrypted is using beautifulsoup4==4.6.0 (for whatever reason)

karmacop avatar Jul 19 '20 02:07 karmacop

A tangential to this: this is an issue also with custom components. The last python-miio bump caused several issue reports due to those custom components being pinned to older versions which overrode the official integration.

rytilahti avatar Jul 19 '20 19:07 rytilahti

There is currently no solution to this. We're limited to how Python dependency management works. It's up to custom integrations to follow what Home Assistant does. Home Assistant will ensure their core dependencies are always the version we expect it to be.

balloob avatar Jul 19 '20 20:07 balloob

Can I suggest:

  1. Changing documentation to note the limitation and that developers should use the same versions of core libraries to stop conflicts
  2. A list of core dependencies and versions used by home assistant so developers can easily see which libraries an version they should target
  3. Some warning for developers when these versions are planning to change or when new libraries (which could conflict with existing third party components) plan to be added?

karmacop avatar Jul 20 '20 13:07 karmacop

@karmacop for your points 2 and 3, you can always take a look at requirements_all.txt to see the versions.

As a potential solution I would like to see the custom components erroring out if they try to do a downgrade instead of silently downgrading the package (can be done using pip constraints, maybe?) and causing problems in core integrations. This way the issue reports would then hopefully go directly to the correct place.

rytilahti avatar Jul 20 '20 15:07 rytilahti

We use pip constraints, but we only constraint anything that is loaded as part of the default_config integration and it's dependencies.

balloob avatar Jul 20 '20 18:07 balloob