n8henrie / fauxmo

Emulated Belkin WeMo devices that work with the Amazon Echo
https://n8henrie.com/2016/02/fauxmo-home-automation-with-the-amazon-echo-raspberry-pi-and-homeassistant/
Other
358 stars 77 forks source link

Uninstalled newer Home Assisstant #19

Closed pr3sidentspence closed 7 years ago

pr3sidentspence commented 7 years ago

My Issue

I had the latest Home Assistant installed on this Pi and when I installed fauxmo from pip it uninstalled it and then installed an older version. Some of the things I had configured no longer work. I wasn't aware this would happen. Did I miss a warning? I'm a bit of a pip noob.

pr3sidentspence commented 7 years ago

FYI, I was able to easily upgrade it again after, once I learned the arguments for pip3 to do so. Afterward, my configuration worked again.

n8henrie commented 7 years ago

This is normal behavior if you install (any package) into your global site-packages that has a conflicting dependency version. Documenting this behavior is outside the scope of Fauxmo, since it's normal behavior for pip. I recommend you read up on virtual environments and the venv tool that's been included with Python since around 3.4.

In short, let's say that hypothetically something in a recent HomeAssistant update broke compatibility with Fauxmo (it hasn't, to my knowledge, however this isn't at all unlikely due to their impressive development pace and release cycles). So in that case, if a user had the latest (and incompatible) HomeAssistant installed, and then the user installed Fauxmo, what should pip do? Which package gets broken? pip's default behavior basically assumed that the package you're currently trying to install has precedence, so it will install (and uninstall) what it needs for that package to work, irrespective of other packages installed into the same environment.

The workaround for this issue is using a "virtual environment" -- which basically blinds Python to anything that hasn't been installed specific to that environment. So, for example, what I've done is to install HomeAssistant (latest version) into its own virtual environment, and Fauxmo into a separate virtual environment (which installs its required and tested version of HomeAssistant there, completely separate from the other HomeAssistant installation). When installing into venvs, you'll then get an executable path that runs inside that environment, protected from other venvs -- for example, you could have /abs/path/to/fauxmo/venv/bin/python and /abs/path/to/fauxmo/venv/bin/fauxmo, and both that python interpreter and that fauxmo console script would only have access to other packages installed into the virtual env at /abs/path/to/fauxmo/venv.

Hopefully that makes some sense. Again, I encourage you read up on venvs and why they are considered a best practice. For me, every project that I work on gets its own venv, and most projects that absolutely have to run reliably get their own as well, which prevents other packages from messing with them.

Closing as this is not a Fauxmo issue -- feel free to continue conversation here though.

pr3sidentspence commented 7 years ago

Thanks for that excellent answer. I will look into this.

pr3sidentspence commented 7 years ago

What does fauxmo rely on home assist for?

n8henrie commented 7 years ago

Unfortunately the "search this repository" doesn't work for code in Fauxmo because it's a forked repo (I may delete and re-upload as "unforked" someday for this reason), or else I would refer you there.

If you look into the fauxmo.handlers module, you'll find that Fauxmo leverages the Home Assistant Python API (links in the README) to bridge the Echo to Home Assistant devices.

I would like to create some kind of user-editable plugin architecture for Fauxmo at some point and allow users to add their own plugins. As part of this, I would remove the HomeAssistant dependency and let people download the HomeAssistant plugin if they wanted that functionality. However, I'm still just in the brainstorming phase of this change.