Leaving this here as an intermediate result of some investigation into the topic of using pixi-build-ros instead of vinca to generate the recipes and build the packages for the ROS distros in RoboStack.
Issues found:
pixi-build-ros doesn't support the concept of patches yet.
We could support this by adding the copy of source into a source folder again like the backends used to do.
- You would still need some script to manage the distro snapshots as a way to fill in the
[package.build.source] for pixi build.
- There needs to be a build orchestrator like
vinca-gha to create the multi stage GitHub Actions workflow file.
This would be a feature that is welcome to Pixi anyway as it would be really cool to have any type of workspace split it's builds into multiple jobs, on any CI server.
Smaller issues:
pixi-build-ros needs to support <group_depend> from a package.xml.
pixi-build-ros needs to support ros2-<package_name> naming convention.
- We need a backend for dummy meta packages where we need to shim conda-forge packages like
ros-xxx-eigenpy.
Claude generated sketch, not perfect but sketches the idea of this comparison.

I feel like this would only align the tools more but wouldn't bring too many UX improvements to RoboStack today. As you would still need to maintain a generator to translate the rosdistro_snapshot into pixi.toml files instead of recipe.yaml files. The robostack.yaml would still need to be maintained.
Where I can see value is in making pixi-build-ros a better tool for ROS development. The required CI job orchestration tool would be a big win for Pixi and the work to maintain vinca can be moved to pixi-build-ros to share more of the effort between the projects.
Leaving this here as an intermediate result of some investigation into the topic of using
pixi-build-rosinstead ofvincato generate the recipes and build the packages for the ROS distros in RoboStack.Issues found:
pixi-build-rosdoesn't support the concept ofpatchesyet.We could support this by adding the copy of source into a source folder again like the backends used to do.
[package.build.source]for pixi build.vinca-ghato create the multi stage GitHub Actions workflow file.This would be a feature that is welcome to Pixi anyway as it would be really cool to have any type of workspace split it's builds into multiple jobs, on any CI server.
Smaller issues:
pixi-build-rosneeds to support<group_depend>from apackage.xml.pixi-build-rosneeds to supportros2-<package_name>naming convention.ros-xxx-eigenpy.Claude generated sketch, not perfect but sketches the idea of this comparison.

I feel like this would only align the tools more but wouldn't bring too many UX improvements to RoboStack today. As you would still need to maintain a generator to translate the rosdistro_snapshot into
pixi.tomlfiles instead ofrecipe.yamlfiles. Therobostack.yamlwould still need to be maintained.Where I can see value is in making
pixi-build-rosa better tool for ROS development. The required CI job orchestration tool would be a big win for Pixi and the work to maintainvincacan be moved topixi-build-rosto share more of the effort between the projects.