I did an upgrade on Raspberry OS to Trixie and now get the following when trying to do a wfpiconsole update:
[i] Installing Python virtual environment… already exists
[i] Installing WeatherFlow PiConsole Python modules…
[✗] Updating Python package manager
Error: Unable to update Python package manager: pip
/home/mfrazier/wfpiconsole/venv/bin/python3: No module named pip
Pip is installed, and trying to reinstall it doesn’t help.
Ok, I was able to resolve this myself. Here is the response from Perplexity.ai when I pasted the original post as a prompt (I removed the top portion of the answer since it was more background information). I followed the steps and was then able to do a wfpiconsole update, and have it back working now. I hope this helps someone else.
Steps to fix:
Remove the old (now broken) venv:
rm -rf /home/<username>/wfpiconsole/venv
Recreate it using the system Python (which now matches the upgraded OS):
python3 -m venv /home/<username>/wfpiconsole/venv
Activate the environment and ensure pip is present:
source /home/<username>/wfpiconsole/venv/bin/activate python -m pip --version
If pip is missing, inside the venv run:
python -m ensurepip
Glad you managed to get it working. Part of the issue may also have been that doing an in-place upgrade in Raspberry Pi OS (rather than imaging a new SD card with the updated OS) is not technically supported. It can be done, but it often results in broken issues like the one you saw
This came up recently for a weewx pip installation user who did the same thing.
It’s a known downside of python venv architecture. Any os change that ‘deletes’ a previous python version (or that changes the default python version python3 points to) causes breakage in all venv setups.
For wfpiconsole I’d suggest the simplest fix is to rename your wfpiconsole directory to save any modifications you might have made, and then do a clean wfpiconsole installation which should resolve everything vs. the new python 3.13 in trixie. That’s 100% certain to work.
Any guidance you get via AI is cross-your-fingers as always.
Possibly related…..
[ - Peter - feature suggestion follows - ]
If you create the venv with “python3.11 -m venv” your venv/bin links will likely be more robust toward this python ‘feature’…
pi@pi5:/tmp $ python --version
Python 3.11.2
pi@pi5:/tmp $ python3.11 -m venv py3.11venv
pi@pi5:/tmp $ ls -al py3.11venv/bin
total 44
drwxr-xr-x 2 pi pi 4096 Sep 21 09:46 .
drwxr-xr-x 5 pi pi 4096 Sep 21 09:46 ..
-rw-r--r-- 1 pi pi 1996 Sep 21 09:46 activate
-rw-r--r-- 1 pi pi 922 Sep 21 09:46 activate.csh
-rw-r--r-- 1 pi pi 2198 Sep 21 09:46 activate.fish
-rw-r--r-- 1 pi pi 9033 Sep 21 09:46 Activate.ps1
-rwxr-xr-x 1 pi pi 235 Sep 21 09:46 pip
-rwxr-xr-x 1 pi pi 235 Sep 21 09:46 pip3
-rwxr-xr-x 1 pi pi 235 Sep 21 09:46 pip3.11
lrwxrwxrwx 1 pi pi 10 Sep 21 09:46 python -> python3.11
lrwxrwxrwx 1 pi pi 10 Sep 21 09:46 python3 -> python3.11
lrwxrwxrwx 1 pi pi 19 Sep 21 09:46 python3.11 -> /usr/bin/python3.11
versus the version independent way
pi@pi5:/tmp $ python -m venv pyvenv
pi@pi5:/tmp $ ls -al pyvenv/bin
total 44
drwxr-xr-x 2 pi pi 4096 Sep 21 09:48 .
drwxr-xr-x 5 pi pi 4096 Sep 21 09:48 ..
-rw-r--r-- 1 pi pi 1984 Sep 21 09:48 activate
-rw-r--r-- 1 pi pi 910 Sep 21 09:48 activate.csh
-rw-r--r-- 1 pi pi 2186 Sep 21 09:48 activate.fish
-rw-r--r-- 1 pi pi 9033 Sep 21 09:48 Activate.ps1
-rwxr-xr-x 1 pi pi 227 Sep 21 09:48 pip
-rwxr-xr-x 1 pi pi 227 Sep 21 09:48 pip3
-rwxr-xr-x 1 pi pi 227 Sep 21 09:48 pip3.11
lrwxrwxrwx 1 pi pi 15 Sep 21 09:48 python -> /usr/bin/python
lrwxrwxrwx 1 pi pi 6 Sep 21 09:48 python3 -> python
lrwxrwxrwx 1 pi pi 6 Sep 21 09:48 python3.11 -> python
See how the second resolves to /usr/bin/python (the OS python) while the first resolves to /usr/bin/python3.11 (a ‘specific’ python present on the system).
Just a thought…