Home Assistant Core using an outdated pip version and/or not finding rust

Installation
1

I’m running Home Assistant Core in my main environment (no venv). Today I tried to update to 2023.7.
There is something weird going on in my installation as it fails finding rust.
However I do have rust installed

pi@raspberrypi:~ $ which rustc
/home/pi/.cargo/bin/rustc
pi@raspberrypi:~ $ rustc --version
rustc 1.71.0 (8ede3aae2 2023-07-12)

While looking into the logs I can see it telling me

[notice] A new release of pip available: 22.3.1 -> 23.2.1
[notice] To update, run: pip3.10 install --upgrade pip

which is pretty weird as I have the latest version installed

pi@raspberrypi:~ $ pip3.10 --version
pip 23.2.1 from /home/pi/.local/lib/python3.10/site-packages/pip (python 3.10)

I can see home assistant installing dependency like this

└─ /usr/local/bin/python3.10 -m pip install --quiet bellows==0.35.8 --timeout 60 --upgrade --constraint /home/pi/.local/lib/python3.10/site-packages/homeassistant/package_cons...

So it seems to take the right python and pip version…

I really cannot understand which version of pip and python is using and why. Also, why wouldn’t it find rustc if it is installed in the system for the pi user? In the past I was able to solve this by installing rust with apt but that version is too outdated now.

2

Note that I’m able to install a package manually by calling the SAME EXACT command that home assistant is calling, i.e.

/usr/local/bin/python3.10 -m pip install --quiet zha-quirks==0.0.101 --timeout 60 --upgrade --constraint /home/pi/.local/lib/python3.10/site-packages/homeassistant/package_constraints.txt --use

but for some reason this fails when it is home assistant doing it, even though it is running with the same user.

3

Not sure about your pip-Version, I’m using Core with a venv, works for me, once in a while it asks me to update pip.
For rust, my notes say that I deinstalled rust and cargo quite a while back with apt and installed it using
curl https://sh.rustup.rs 2 -sSf | sh

Armin

4

I already used that. As you can see from the command I have the latest rustc installed

5

Can you show the error you get about rustc?
If I recall correctly, I had rust installed with my “homeassistant”-user ( the user configured for systemd to run the HA service ), not with the “pi”-user. Some dependencies are installed by this service after it is started and this services likely does not have access to the “.cargo” folder in your “pi”-user’s home directory.

Armin

6

yeah, that’s because you installed home assistant with the homeassistant user, but in my case I installed everything under pi in order to avoid exactly these kind of issues.

In my case there is only the pi user and all packages (python, home assistant, rustc,…) are installed under this user.

That’s why I cannot wrap my head around this error

7

sorry when it sounds like asking stupid questions…
In your installation the homeassistant service is configured in the systemd configuration to run as “pi”-user? Or you start the “hass”-script manually?

Armin

8

There are no stupid questions, I’m glad you’re trying to help.

This is my systemctl service started as pi

[Unit]
Description=Home Assistant
After=network-online.target

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/.homeassistant
ExecStart=/usr/local/bin/python3.10 /home/pi/.local/bin/hass -c "/home/pi/.homeassistant"
RestartForceExitStatus=100

[Install]
WantedBy=multi-user.target

And this is the script it’s calling (/usr/local/bin/python3.10 /home/pi/.local/bin/hass)

#!/usr/local/bin/python3.10
# -*- coding: utf-8 -*-
import re
import sys
from homeassistant.__main__ import main
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(main())
9

Hi
looks ok to me
you get the same errors when you start homeassistant from the shell with
/home/pi/.local/bin/hass -c "/home/pi/.homeassistant"

Armin

10

Where are you activating your venv when starting HA?

11

It seems so, but I haven’t tried properly because I was getting all sorts of different errors so, in order not to waste my day, I decided to rollback to 2023.6.3 and for now everything has been working ok.

The problem seem to come from the fact that the environment where hass is running is not the same one that I have when running a normal interactive session.

12

I’m not activating it because I don’t have a venv (first post)

13

Right, I missed that. You shouldn’t be installing things in your system Python. This is why things are getting messed up regarding what’s being used. Just save yourself a lot of trouble and switch to a venv and leave the system Python one. It’s pretty easy to do.

To check which executable is being used, run e.g. which python or which pip.

14

Well, as I’m using python 3.10 ONLY for Home Assistant, there is really no reason to create another venv. Things should even be easier without a venv because you don’t have to create a new user with right permissions, remember to activate the environment before running…
I don’t really understand why this is the suggested way of installing home assistant provided that the system python on a system like raspberry is most likely only used for home assistant.

15

Because HA installs a huge amount of libraries: sensitive things like SSL libraries and often underlying system libraries (to name but one).

Please, I have more than 20 years experience with Python. The fact that you don’t understand is enough reason why you should follow this advice.

Every (good) Python guide out there and HA’s own documentation is advising you to do so. If you don’t follow the recommended installation best practices, then you can’t really expect help.

Creating a new user and a venv is trivial.

1 Like
16

So, I may have found something…

I tried to create a “test” service just to see in which environment hass is running and I quickly discovered that the PATH environment variable was missing something.

This is what hass was seeing:

'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' and this is what an interactive session would have:

'PATH': '/home/pi/.local/bin:/home/pi/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games'

Seeing this it was clear that hass would never be able to find either the right pip3.10 or rustc because they are located in /home/pi/.local/bin/pip3.10 and /home/pi/.cargo/bin/rustc, respectively.

So I added this to my service file

Environment=PATH='/home/pi/.local/bin:/home/pi/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

And now I have the correct PATH where running hass.

At the next update I’ll try to see if that fixes the issue but I have the strong feeling this was the issue.

17

I’m not creating a venv and a new user not because I don’t know how to do that, but because I find it unnecessary in this case.
Most HA guides advise people to install into a venv because they are targeted towards users that don’t really know how to maintain their own Python installation. But I do maintain my own installation, and I want to clutter my environment as little as possible.
I already had to install a new environment just for python 3.10 (as Home Assistant already deprecated 3.9) and I’ll shortly have to do the same for Python 3.11 (please stop deprecating so fast :smiley: ).
I hear your point, just agree to disagree :slight_smile: Especially since, in this case, the problem arises from the way hass is called from systemd and not really from the fact that hass is installed into a venv.

Thank you for the support anyway!

18

Bad news, it’s getting faster :wink:

Oh, and you shouldn’t upgrade pip - that can cause problems. HA will upgrade it when required.

19

Yep, I discovered that the hard way :smiley:

I understand that for most of the people the deprecation is a non-issue (as they’re running in Docker or directly into a system installation) but for the small percentage of the users having raspbian maintaining Home Assistant is becoming quite hard… Just saying :slight_smile:

20

Pffft, I run Core in a venv using pyenv. It’s the work of moments to spin up a new venv with a new version of python.

Of course, if you want easy use Docker/Podman.