Consider using per-package virtualenvs

[hello-binit]

Python nodes in ROS2 use the system interpreter and its pip cache of libraries. There are projects that enable Colcon to create an individual virtual environment for each ROS2 package, each with its own set of pip library caches.

Currently, Web Teleop has a dependency on Pinocchio, which has a dependency on cmeel-boost, which has a dependency on a specific version of Numpy. Simultaneously, Stretch Body uses Trimesh, which has a dependency on a specific version of Numpy. Keeping both Pinocchio and Trimesh happy has been a trial-and-error process of downgrading and upgrading Numpy until we've found a version that makes both happy. There's a couple reasons why this sucks:

• pip tracks version dependencies, but doesn't enforce them. In practice, this means there's nothing stopping you from breaking your installation. Users can accidentally upgrade Numpy, without realizing that they're breaking Web Teleop and the viz tools based on Trimesh. Pip will print out a warning when/if the user upgrades Numpy, but it doesn't prescribe a fix or give the user a clue as to what downstream software might have been broken
• We have to play this game of trial-and-error version searching for every additional piece of software that we write. If my new package has a dependency on foobar, which needs another specific version of Numpy, I'll have to do another search. Furthermore, there might not even be a version of Numpy that satisfies all 3 packages' needs.
• Users needs to play this game too. If their new Stretch software requires a certain version of Numpy, they'll need to be careful to keep our Stretch software happy.

Per-package isolation of Python environments could be the solution to this "dependency hell". It enables Web Teleop to take the version of Numpy that Pinocchio wants, separate from the system interpreter. One complication is that it's common for ROS packages to want access to Stretch Body's modules, e.g. to reach robot parameters to decide how sensitive the robot's guarded contact should be, or what tool/end-effector is attached to the robot. If we isolate the package from the system interpreter, then the package cannot access Stretch Body. Perhaps this could be resolved by including a dependency on Stretch Body within the virtual env. But it remains to be seen how two different version of Stretch Body (the one in the virtual env could potentially be much older than the one in the system interpreter because the system version is updated by the stretch_system_check.py CLI) would interact/interfere with each other.