deploy to virtualenv on robot

[virtuald]

There are some packaging issues that need to be resolved wrt numpy/openblas, but I expect that in 2027 we'll need to install to a virtualenv to avoid conflicting with the system python, so might as well do it sooner rather than later. Will also allow us to use rip/uv if we desire which should make installs way faster (#100).

[cwl5535]

What are the limitations of the upcoming controller? Can we leverage pixi or conda environments to use pixi-pack or conda-pack to deploy? I believe all the controller would need to do is unzip a folder and run a .bat/.sh.

[virtuald]

Currently, we run pip over SSH (https://github.com/robotpy/robotpy-installer/blob/main/robotpy_installer/installer.py#L532) and install whatever the user has specified in their robotpy section of pyproject.toml (see https://docs.wpilib.org/en/stable/docs/software/python/pyproject_toml.html). The current controller doesn't have python installed on it, so we control it 100% (and in fact the robotpy deploy command will install it if not present).

On the new controller (https://community.firstinspires.org/introducing-the-future-mobile-robot-controller) there's already a python installed and likely a bunch of random stuff installed, so we would definitely not want to mess with that but set up a virtualenv or some other isolated environment.

---

The challenge with something like conda-pack is that the user might be running on x86 windows and the controller is arm... I imagine conda-pack probably doesn't support going across architectures when native dependencies are involved?

I've tried to avoid the conda ecosystem so far, mostly because the current workflow for students is "install a python interpreter" followed by "pip install robotpy" followed by (assuming you already have a robot project) "python -m robotpy sync" followed by "python -m robotpy deploy". It's fairly straightforward and doesn't involve some of the magic that you have to learn if you're using conda. I'm open to conda if there's a good reason to leverage it -- but my experience has always been that it's a lot more complicated than "just" python+pip.

[virtuald]

Thinking about it, probably it would make sense to create a docker image or some other mock "robot" environment to prototype some of this stuff in (and then we could use it to actually add tests!? #6 ) since HW isn't going to be available for a bit. Once a real system image is available we could use that to make better tests/dev environment.

[cwl5535]

Interesting. So it looks like there's a server that hosts the wheels and you have pip on the controller SSH and retrieve the wheels from there and everything is build on robot?

As for environments, check out pixi if you get a chance. In the pyproject.toml or pixi.toml you can specify platforms and it will verify your dependencies based on your specified platforms/architectures. Same with the deployment process.

As for instructions, the students shouldn't have to do more than unzip and run a few CLI commands to unpack the environment and be able to run the scripts. Wheels should be built already and you should have the environment you started with on the computer.

And for those eager to try ROS, ROS2 has a pixi environment.

[virtuald]

Interesting. So it looks like there's a server that hosts the wheels and you have pip on the controller SSH and retrieve the wheels from there and everything is build on robot?

Yes. Specifically, when connected to the internet, the robotpy sync command runs a monkeypatched pip to run pip download to get the wheels that your project needs for roborio into a cache. Then, when you're connected to the robot (which is typically a separate wifi network connected to the internet) we SSH over to the robot and use SSH port forwarding to serve that cache to the robot, so that pip install --find-links localhost:port can find and install the necessary wheels. Since everything is a wheel, it's fast enough and doesn't require much from the robot controller.

---

It seems that pixi also uses conda, and currently all of our native wheels are built+uploaded to pypi and a custom index. I'm hesitant to migrate to a conda-focused setup.

The other thing about the pixi setup is that I think it provides far more flexibility than I would want to provide to our users. Specifically, there really isn't a need for our users to know the specifics of the robot platform and could be confusing for high school students just starting out with little/no mentor support, so I'd rather them not have to define the workspace-specific channel/platform information -- even if we just said "copy/paste this magic every time" I'd rather not introduce that extra step.

It might make sense to wrap a tool like pixi to accomplish everything for the user if there was a good way to hide everything from them.

[virtuald]

Fixed in #147 for 2027. Unlikely to backport to 2026.