While I am not a Python venv proponent, there are many folk that are. Recently a new GoPiGo3 user had difficulty setting up the GoPiGo3 to run in a virtual environment.
There are generally two methods of creating a virtual environment:
- clean: start with a clean Python environment, then install only desired packages and versions
- copy/link-system: start with a copy of or link to all packages and versions of the “system”
The DI/ModRobotics github suggests for setting up a “clean” virtual environment to use::
curl -kL dexterindustries.com/update_gopigo3 | bash -s -- --user-local --bypass-gui-installation
I have not tested that method over the Legacy PiOS to know if it succeeds or not.
The “copy-system” setup method, which I did verify, is to
- Install the GoPiGo3 software system-wide on Legacy PiOS, and verify a working “system”
$ curl -kL dexterindustries.com/update_gopigo3 | bash
$ curl -kL dexterindustries.com/update_sensors | bash
$ python3 ~/Dexter/GoPiGo3/Software/Python/Examples/Read_Info.py
- Create a copy-system virtual environment, and verify GoPiGo3 continues to work in the virtual env.
$ mkdir /home/pi/testvenvwsite
$ python3 -m venv --system-site-packages
$ source /home/pi/testvenvwsite/bin/activate
(testvenvwsite) $ cd ~/Dexter/GoPiGo3/Software/Python/Examples/
(testvenvwsite) $ python3 Read_Info.py
(testvenvwsite) $ deactivate
When GoPiGo3 robots start to add multiple, complex computational packages with specific version dependancies, virtual environments allow progress without having to have separate systems for each configuration, and prevent a need to rebuild or restore the system when conflicts arise.
For most beginning GoPiGo3 users, the advice to avoid virtual environments is probably appropriate.