TL;DR - You will have to change how you install ROS 2 on Windows, for Rolling, Jazzy, and Humble. The good news is that it should be much simpler than before.
What are we doing?
We are changing how the dependencies necessary to build and run ROS 2 are installed on Windows. In particular, we are switching to using pixi to install and manage our dependencies. This has several advantages:
The installation process is significantly simplified. Instead of dozens of steps to install dependencies, it is just a couple of commands.
It is much easier to update dependencies, so in the future we shouldn’t have long periods of time stuck on obsolete versions (I’m looking at you, Python 3.8).
The dependencies are installed in individual workspaces, with no “global” installation. Thus it is easy to work on multiple ROS distributions on the same machine.
Who will be impacted?
All users of ROS 2 on Windows will be impacted by this change. If you don’t use ROS 2 on Windows, nothing will change for you.
Unlike most changes we do, this also applies to our stable Humble and Jazzy users. While we try to not make big changes for stable distributions, in this case it would be too much work to maintain CI and packaging jobs for the stable distributions, the installation instructions for them would still be complicated, and they would still be using very outdated dependencies.
How are we doing this?
There is a series of pull requests that implement this. The first set added a pixi.toml file for each of the distributions:
Once those two PRs are merged, the next release of the respective distributions (Humble, Jazzy, and eventually Kilted) will only work properly using the new dependency system.
Questions?
If you have questions or comments about this change, please leave them in this thread and we’ll work through them with you.
Added to all what @clalancette has explained in the post above, I would like also to add that for the ROS 2 Windows platform we are using the great conda-forge packages as the only source to get the binaries for all the ROS 2 Windows CI dependencies.
I also would like to thanks to the Robostack project, @traversaro, @Tobias_Fischer, @wolfv, etc. for the help and work on the conda-forge packages over the last years.
I was overexcited and already tried out the instructions only to realize that the latest release zip wasn’t built with python 3.12 yet. I’ll wait patiently until the nex release is available but if you need any testing help let me know.
Gazebo for windows have been using Conda-forge as well. Is the plan for it to also use pixi so we can have a toml file to rule them all?
I am not a windows user but would love to be able to use pixi more as part of my ROS workflows on Linux. Do these changes mean there will be more Ros packages available via conda-forge/robostack for linux as well?
Not at the moment, no. This will only change the installation of the ROS 2 core dependencies to using pixi/conda.
That said, this definitely opens the door to a more close collaboration between the ROS 2 project and the folks at Robostack, who have been rebuilding ROS 2 packages for a few years now.
I’d just like to share my appreciation for the efforts here. I went through the instructions to build ROS 2 rolling from source on Windows and had a working environment in under an hour. My windows computer at work is heavily locked down. I don’t have administrator access, and this has made ROS development exceedingly difficult to set up in the past.
Pixi eliminates all those problems I had before. I was able to reproduce a windows CI error I saw on the build farm locally. Being able to compile ROS applications natively on Windows with minimal setup now is such a blessing.
pixi shell is needed to properly activated the pixi environment, a bit like install\setup.bat activates the ROS software, i.e. it makes it available by modifying appropriately the environmental variables. If you do not want to open a new shell (like pixi shell does), you can also see the environment modified with pixi shell-hook. Just to understand, why calling pixi shell is a problem while calling install\setup.bat is not a problem?
I would really like to see a much closer collaboration between OSRF and RoboStack regarding the packaging and distribution of ROS 2. Replacing the system-specific and native packaging (DEB/RPM/…) with a single conda / RoboStack workflow should free up a lot of resources and maintenance burden, and also disentangles ROS from Ubuntu.
Especially for education and research, being able to install ROS as non-root user independently of the system and together with common machine learning frameworks is a huge improvement compared to the current solution of using the ROS system packages mixed with other pip packages and environments.
So, as a long-time ROS users, I would really like to see the ROS native system packages replaced by RoboStack.
not a problem of pixi shell at all, just wan to confirm if it’s a problem of myself
A follow-up question, if I have 2 workspace, one is ros2 source, another one is someother_ws, how to call the ros2’s pixi shell from someother_ws ?
In ros2, even in someother_ws, I only need to call the local install/setup.bash without calling /opt/ros/humble/setup.bash. Then in pixi, in my case, should I call pixi shell twice? it’s still ok for me, just want to learn how to use pixi in that case.
Interesting, I was not aware of that. Do you have any idea of which piece of code insert the call to /opt/ros/humble/setup.bash in install/setup.bash ?
