How does Nix fit into the ROS 2 ecosystem?

Nix is a featureful package manager and build tool. Where exactly can it fit in to the existing ROS 2 ecosystem? Let’s explore.

The standard ROS 2 build responsibility chain

Imagine a regular ROS 2 environment, on a regular Linux distribution.

Software (both regular and ROS 2) is installed via the system package manager, typically from the official distribution or ROS software repositories. The collection of available software is heavily tied to the distribution. If your distro goes EOL, you’re SOL - no more updates for you.

colcon is the primary tool used to manage local ROS workspace installations, and build packages. It is a “build tool” that acts as an abstraction layer over various “build systems” such as setuptools or CMake, and configures such build systems to find ROS package dependencies before starting them.

These technologies can be laid out in a “chain of responsibilities” diagram, like so.

aPmsyeetnthtuo_pnptyocRLtooOiRhldSnOpose-uSacncxcoadklpdiacaisgobstenltrsaeromCoe+nC+tM_acckomedaeke>>>>>>>>>PPPPoLECABrrrrfexLduoooofteIdivvvviscsliiiicuedddddibtnRseeeeauetOsssslisrSa,lynOpnRdbpfdSaoaOuoecnnSsiiapsk-dylntaeaRpsdtucrgOlatrkveSeceseaitkmysgcmssasseeaogttssnfbefeoatusimRgwinssOealdtSrrdaewnpsodayracskrktsdaepgmabescuseiflipdnadcs,kyasgteesms

The ROS 2 build responsibility chain with Nix

Nix is quite well suited to the roles of both the system package manager and colcon.

Just like the system package manager, Nix provides a large collection of independent regular and ROS packages. Just like colcon, it is a build tool designed to configure build environments and run build systems inside them.

Using Nix, our responsibility chain now looks like this.

aPmsyeetnthtuo_pnptyocNtooAihldnxoseydniNoLsiritxnrcuooxlacmCoe+nnC+tM_acckomedaeke>>>>>>>>PPPoLECABrrrfexLduooofteIdivvviscsliiicueddddibtnRseeeauetOssslisrSa,lynOnRdbpfdSoaOuoennSsiiaps-dylntaeRpsdtucrOlatrkvSeceseaitkmysgcssasseeogttssfbefeotusimRwinssOaldtSrdaewnpsodayracskrktsdaepgmabescuseiflipdnadcs,kyasgteesms

Nix or colcon?

Nix is almost always an upgrade over the system package manager, but at the package development level, the choice of build tool is not often so easy. Both Nix and colcon have their own benefits and drawbacks in various situations.

Reasons to use Nix

  • Nix allows you to start a shell in any package’s build environment, letting you work with the lowest-level build system directly. This is especially useful when working with IDEs, as no special ROS-specific setup is required.
  • Nix packages can be easily deployed to any device. Using nix-copy-closure or substituters, a package can be copied to another device along with all its runtime dependencies. This means that ROS packages can be built in advance on powerful hardware to be later sent to a low-power embeded device.
  • Nix builds never fail on account of missing dependencies. Unlike colcon, which relies on manual invokation of external tools such as rosdep to install dependencies, Nix sets up the entire build environment for each package itself, and prevents undeclared system software from being seen by the build system.
  • Nix has a rich tooling ecosystem. Nix packages can be easily integrated into NixOS systems, and CI/CD is well supported by Hydra.

Reasons to use colcon

  • colcon is good at working with multiple packages at once. It can generate setup scripts that allow all the packages being developed to see each other. Nix can do this too, but it is not designed with this use case in mind. Acheiving this with incremental compilation in Nix is difficult.

  • colcon is faster for rapid iteration. The build tool has features such as --symlink-install and built-in support for incremental compilation to allow packages to be modified swiftly. Nix cannot do either of these things easily.

  • colcon can build any ROS package with no extra configuration, as long as the dependencies are available. ROS packages built with Nix must first have derivations written, which makes it harder to get started quickly.

Which build tool should I use?

I recommend using a combination of Nix and colcon. Nix, for single-package development (due to the ease of IDE integration), deployment, and CI/CD; and colcon, for multi-package development.