Custom_component that requires different version of library compared to standard component

Installation Home Assistant OS
1

I am not sure if this is a 0.94 or a hass.io or a hass.io-running-in-docker-instance issue, but I’m having trouble with a custom_component that has a manifest.json with requirements of “elkm1-lib==0.7.15”. Obviously, this conflicts with the standard component elkm1 which uses elkm1-lib==0.7.13. The logs show

INFO (SyncWorker_7) [homeassistant.util.package] Attempting install of elkm1-lib==0.7.15

But then no warning about that failing, yet it seems to fail: When I run a shell in the docker image, I don’t see the newer elkm1-lib in /usr/local/lib/python3.7/site-packages/ – just the old one.

I was able to fix this by explicitly doing the pip3 install of the right version inside the docker image (since I don’t actually need the old version at all – not sure how it would work if both versions were requirements for different reasons).

2

I’ve a similar case. Overriding the version package before the update to 0.94.0 was working. I can’t succeed since the latest update.
I’m not familiar with docker image can you explain or link me to documentation to find a way to implement your workaround ?

3

Hassio addons are all in their own docker images to avoid such conflicts. There is documentation and a tutorial in the development documentation.

4

Sure, but I’m not talking about a hass.io add on. Just the core home assistant functionality running in a hass.io docker container. The protections between custom components and core component dependencies are not at a docker boundary as all of those components run inside the same docker image and same python process.

5

Just run a shell such as bash inside the homeassistant docker image and do a pip3 install forcing whatever version you need of the library.

6

And that will break on the next Hassio update. Been there, done that.
The component designer need to make it a Hassio plugin if he wishes Hassio users to use it.

7

Yep, and that’s why I’m asking why the behaviour of the loader is broken in this way.

Shouldn’t the loader/dependency management system just upgrade to the version required by the custom_component’s manifest.json? If the component has the same name as the built-in component and the only place where the library is used is that built-in component, then the older version is no longer necessary as the custom_component should be fully-overriding the built-in code.

This seems like a common case where new functionality is needed. An author updates an upstream PyPi library, creates a custom_component copying the built-in functionality but updating the manifest.json to point at the new library and making whatever other changes are needed for the component, and then expects that to work, but it doesn’t.

In my case I’ve also submitted the change for inclusion in home assistant, but I still need to use my version of the component in the meantime.

8

Did you ever get an answer to this? I found myself with the same problem today. I forked a custom component as well as a library it depends on. I updated the manifest.json but I still have the older library installed.