:focal(smart))
My first motivation is related to teaching. The courses I teach at Universidad Rey Juan Carlos are “Software Architectures for Robots” and “Planning and Cognitive Systems.” In both, I use ROS 2 and require the installation of software packages such as Nav2 and PlanSys2, as well as various simulation environments in the Linux laboratories of the School. These laboratories consist of around ten classrooms with 40–70 networked computers each, where students attend lectures and carry out practical assignments. Recently, installing deb packages has no longer been straightforward, and installing an additional package beyond the ROS 2 desktop installation can take almost a week from the moment it is requested until it becomes available. If a package required to compile or run the software repositories used in my courses is missing, then a new request has to be submitted again. At the Intelligent Robotics Lab, we thought that using Pixi, which allows complete ROS 2 installations managed entirely in user space, could be a solution to this problem, with the minor drawback of increased disk usage in each student’s account. However, we can accept this in exchange for allowing students to install dependencies by themselves without relying on system administrators.
My second motivation is related to managing releases of the ROS 2 packages we maintain: PlanSys2, Yaets, EasyNav, MOCAP4ROS2, among others. Since I started working with PlanSys2, I have wanted to contribute binary packages for all active ROS 2 distributions. The release process is not complex, and much of the work is handled very efficiently by the distro maintainers at Open Robotics, to whom I am very grateful for their efforts. However, this process has a dark side: even if you successfully compile and test on your own computer, including with Docker containers, reproducing what happens in the build farm is difficult. It is very common that once your pull requests are merged into ROS Distro, build farm error messages start flooding your email inbox once or twice a day. Fixing these issues is not always easy, and it involves preparing a fix, making a new release while bumping the version, submitting another pull request to ROS Distro, and crossing your fingers. This may require several iterations during which you are repeatedly bothering the distro maintainers. For many years, I have tried to gather information on how to reproduce the ROS 2 build farm locally as a step before submitting to ROS Distro, but it has always been a dead end. Being able to have a local build farm to create my own binary packages is something I have wanted ever since I started contributing software to ROS 2, and Pixi has ultimately become the solution.
With these motivations in mind, I used these days to explore Pixi. I had already submitted a pull request to RoboStack so that PlanSys2 would become available there, and it had not seemed complicated to me. In this case, I followed the Pixi and RoboStack tutorials. I started with simple ROS 2 workspaces and set myself the goal of getting the workspaces used in the courses I teach running, together with the simulation environments we use in them. Since not all the ROS 2 packages I used were already available in RoboStack, instead of immediately starting to submit pull requests to RoboStack and waiting for them to become available, I cloned the RoboStack repositories containing the machinery required to create binary packages locally and started completing my own dependencies. I had my own build farm on my own computer!!! Moreover, the packages I created could not only be used locally to compile the workspaces for my courses, but I could also upload them to my own public channel on prefix.dev and use them from there in combination with the RoboStack channels, gradually moving the more general-purpose packages from my channel into RoboStack. I was already solving the package installation problem in my university laboratories.
There has recently been a great deal of discussion on ROS Discourse about the possibility of using package managers to distribute software within the ROS ecosystem. I believe that Pixi (with Conda as its foundation) or Conan offer many possibilities for having a better packaging system than the current ROS Buildfarm approach. In addition, this would open many opportunities, such as enabling organizations or companies to have their own channels for building and distributing their software without depending on a system as centralized and difficult to reproduce as the current one.
In the end, this exploration has been much more than simply learning a new tool. Pixi and RoboStack have shown me that it is possible to rethink how we develop, distribute, teach, and maintain ROS 2 software. From improving reproducibility in academic laboratories to enabling local build farms and independent distribution channels, these tools open the door to workflows that are more flexible, decentralized, and developer-friendly than the current ecosystem. I still believe there are many challenges ahead, especially regarding adoption and ecosystem maturity, but after these weeks of experimentation, I am convinced that this direction has enormous potential for both academia and industry within the ROS community.
A massive thank you to Francisco for sharing this with our community!
Building something cool with pixi, rattler-build, or anything in our ecosystem? We'd love to feature your story too. Contact us through hi@prefix.dev
