Workspace chaining like in ROS and distribution using Debian packages #6411

simonschmeisser · 2026-06-20T10:48:47Z

simonschmeisser
Jun 20, 2026

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 · 2026-06-21T11:55:24Z

krotname
Jun 21, 2026

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.

0 replies

ATemova · 2026-07-07T10:22:28Z

ATemova
Jul 7, 2026

Hi Simon — yes, this is doable, and pixi actually fits your setup better than it might first appear. Your instinct is close, but there's one important reframing: pixi/conda packages aren't Debian packages, so the model isn't "store /opt/ros and /opt/optonic inside a versioned .deb." It's the parallel conda-world equivalent, which maps cleanly onto your three layers.

How your layering translates

Your current stack is: Ubuntu base → apt ROS → /opt/optonic platform (forked ROS deps) → workspace components. The pixi equivalent, via RoboStack (the community project that repackages ROS as conda packages on top of conda-forge), is structurally identical — a base distribution (conda-forge) with a ROS channel layered on top (robostack-), exactly mirroring Ubuntu + packages.ros.org. Note pixi/RoboStack are currently a Tier 3 (community-supported, not officially OSRF-supported) platform in the ROS ecosystem, which matters for a multi-year production commitment.

Base + upstream ROS → a pixi workspace pulling from robostack-<distro> + conda-forge. A pixi.lock file pins every dependency including transitive ones, with checksums — this is the big win over apt for reproducibility, and it's what lets you guarantee the exact same environment on a dev laptop and on the robot.
Your /opt/optonic platform (forked deps) → build these as conda packages using the pixi-build-ros backend and publish them to your own private conda channel. That channel is your versioned "platform" layer. (Heads up: pixi-build is still a preview feature — fine to evaluate, but factor that into a multi-year plan.)
Individual components → same pattern: each builds to a conda package depending on your platform channel, or during development you use path dependencies ({ path = "src/my_pkg" }) to override exactly the components a developer is working on. That preserves your "install everything, override what you're hacking on" workflow directly.

The air-gapped part — t 8000 his is the key question, and it's well supported

For offline/USB-stick distribution, look at pixi-pack (github.com/Quantco/pixi-pack). It packs a resolved pixi environment into a single archive that you unpack on the target machine with no network access — which is precisely your "email + USB stick to a field engineer" workflow. This is the conda-world answer to shipping a self-contained versioned bundle, and it's arguably cleaner than reconstructing an apt repo on an air-gapped box. You can pack the whole environment (locked to a pixi.lock) so what the field engineer unpacks is bit-for-bit what you tested.

Two caveats worth knowing before you commit

rosdep does not work inside a pixi environment — it calls apt/pip under the hood, which bypasses pixi. You manage dependencies with pixi add instead. There's a helper, pixi-ros (ruben-arts/pixi-ros), that reads your existing package.xml files and generates the pixi.toml, which eases the transition from a rosdep-based workflow considerably.
RoboStack coverage isn't 100%. Core ROS is well covered, but check your specific forked/niche dependencies exist in robostack-<distro> (browse on prefix.dev). Anything missing you'd either package yourself with pixi-build-ros or contribute upstream to RoboStack.

On the ROS 1 → ROS 2 point: RoboStack does have robostack-noetic, so you can pixi-fy your current ROS 1 stack today. But given pixi-build-ros is preview and you're already planning a catkin→colcon / ROS 1→ROS 2 migration, the pragmatic path is probably to pilot pixi on a ROS 2 component first (where colcon + the build backend are the forward-looking target) rather than invest heavily in wrapping the Noetic stack you intend to retire.

Short version: your mental model works if you swap "versioned Debian package" for "versioned conda package in a private channel," and use pixi-pack for the air-gapped USB-stick distribution. The workspace-override dev workflow you like is natively supported via path dependencies. The main risks for a multi-year commitment are the Tier 3 status and that the build/packaging backend is still preview — worth weighing, but the core approach is sound.

Happy to go deeper on any layer if useful.

0 replies

Navigation Menu

Uh oh!

Workspace chaining like in ROS and distribution using Debian packages #6411

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Workspace chaining like in ROS and distribution using Debian packages #6411

Uh oh!

simonschmeisser Jun 20, 2026

Replies: 2 comments

Uh oh!

krotname Jun 21, 2026

Uh oh!

ATemova Jul 7, 2026

simonschmeisser
Jun 20, 2026

krotname
Jun 21, 2026

ATemova
Jul 7, 2026