Workspace chaining like in ROS and distribution using Debian packages

[simonschmeisser]

Hi there,

a colleague pointed me to pixi and I'm trying to understand if and how it could fit our requirements. We control industrial robots from Linux computers. Those are often air-gaped for various reasons. Currently we have a bunch of dependencies packaged as Debian packages (Qt, ROS 1, ...) atop of a generic Ubuntu 22.04. Next layer is workspace where we have all ROS dependencies that we forked in some way (we call it the platform). This is distributed via Debian packages as well. Then individual components of our system are build as Debian packages. This allows for a quite agile workflow where components can be adapted and extended individually and quickly even via email + usb stick by field engineers (or customers).

For local development we install the same packages and source the workspace. Then we can override whatever components a developer wants to work on.

From a ROS perspective we have

/opt/ros/one/...
/opt/optonic/... extending /opt/ros/

/home/xyz/workspace/... extending /opt/optonic/...

What I think I want is to have a pixi env that contains /opt/ros/..., /opt/optonic stored inside some Debian package with a version number. And individual components that depend on it and can be installed as further Debian packages.

Does that sound doable?

We currently use catkin-tools and ROS 1 but switching to colcon and ROS 2 should happen at some point as well

Thanks a lot and sorry for the vague question
Simon

[krotname]

I think Pixi fits the reproducible/offline robotics environment part well, but I would not model the internal layers as Debian packages inside the Pixi environment.

The Pixi-native shape is closer to this:

• use conda-forge as the base distribution and robostack-<distro> as the ROS channel, analogous to Ubuntu + packages.ros.org;
• package your /opt/optonic layer and reusable components as conda packages, ideally with pixi-build-ros for ROS packages, and publish them to an internal conda channel;
• make downstream workspaces depend on those packages in pixi.toml, with the exact result locked in pixi.lock.

For active development, I would keep the source workspace separate and let Pixi drive the ROS build. For ROS 2/colcon the documented pattern is a Pixi task like:

[tasks]
build = "colcon build --symlink-install"

[activation]
scripts = ["install/setup.sh"]

After the first build, Pixi runs the activation script on pixi run / pixi shell, so the built overlay is available without manually sourcing it each time.

For air-gapped deployment, pixi-pack is probably the more direct fit than Debian dependency layering. It can create an archive of the resolved environment, pixi-unpack can recreate it on the target without conda/micromamba installed, and --inject can add locally built .conda packages or wheels. If your organization requires .deb delivery, I would treat the Debian package as an outer installer for a packed Pixi environment, not as the dependency model inside Pixi.

A few caveats:

• only one Pixi environment is active at a time, so I would express reusable layers as package dependencies/channels rather than trying to stack active Pixi envs;
• rosdep is not the right mechanism here, because it calls apt/pip outside Pixi; missing deps should be added as Pixi/conda deps or packaged;
• the current docs are strongest around ROS 2/colcon and RoboStack; for ROS 1/catkin you should first verify that your needed packages exist in RoboStack, and expect to package missing ones yourself;
• for robot host assumptions such as glibc/CUDA, declare them as Pixi platform/virtual-package constraints so the lockfile matches the deployment machines.

So: yes, Pixi can fit this kind of industrial/offline workflow, but the clean migration is from "Debian packages layered under /opt" to "conda packages in private channels + locked Pixi environments + packed deployment artifacts". Keeping .deb as an external transport wrapper is feasible, but making .deb the primary unit inside Pixi would fight the tool.