Build Systems, Package Management, and Nix

Next Generation ROS
,
1

Happy new year! As you may know, a new year means a new debate about ROS tooling… /j

If your reaction to this title is, “not another beginner coming to this forum to voice their displeasure with bespoke build tools within the ROS ecosystem,” I’d encourage you to read it before responding, as I believe the ideas expressed here are substantially different from previous posts.

I have read through essentially endless arguments on this forum regarding bespoke build system and package distribution tools within the ROS ecosystem, as well the Universal Build Tool design document.

Based on the doc, and personal experience, the technical requirements of a build and packaging system for ROS are very (uniquely) challenging because:

  • Users must be able to develop multiple packages simultaneously
  • Packages must be able to be written in any language and built with any build tool
  • Packages must be published for specific ROS releases, which need to work on multiple operating systems
  • I might be missing something

This is indeed a very complex problem, and it’s one that “just using cmake” does not come close to solving. Usually, the anti-bespoke-tooling-crowd is told to put in the work to think of a better solution or replace colcon/ament, which is understandable, since there aren’t very obvious better solutions (foreshadowing).

The current approach taken to solve these problems in the ROS ecosystem is through colcon to build arbitrary numbers of C++ and Python packages with ament, rosdep to wrap operating-system specific package managers, and vcstool to wrap version control systems. In theory, these provide necessary abstractions for ROS users to effectively manage their packages and dependencies.

As someone who has been working on software infrastructure for an autonomous vehicle, which depends on the full extent of ROS2 tooling, along with podman, to handle everything ranging from nicely packaged device drivers on ros index to git repositories with outdated academic paper implementations… I have found that these tools do little to mitigate dependency hell.

“Oh God This Guy Is Gonna Start Preaching Nix”

I recently started building a project with Nix for unrelated reasons, and as I was learning, I couldn’t help but think of just how useful this would be in ROS projects. Someone much more talented than me has put in the work already to make this possible, with nix-ros-overlay. This project automatically rebuilds and distributes every/almost every package in supported ros distros’ package indexes as nix packages. I am writing this post because I couldn’t find any discussion on here about the project.

To very briefly describe what Nix is: It is a package manager based around representing “derivations” (build steps) as pure functions, meaning all package builds are fully reproducible because they are not impacted by system state. This is accomplished via a lazily evaluated functional programming language/DSL with the same name.

Some of the benefits from building and distributing ROS packages through Nix (flakes) are:

  • All packages are reproducible, and can be built from source
    • This is very beneficial in the context of the ROS ecosystem, because engineers are often utilizing tools published by researchers based on old tech stacks and not actively maintained.
  • Significantly less maintenance burden
    • Any bespoke ROS build tooling is either optional or redundant. For example, nix-ros-overlay can wrap ament-cmake, but projects written with nix can get away with using standard cmake for building their C++. Projects like vcstool and rosdep are replaced by a more programmatic solution, since Nix derivations deterministically properly handle dependencies from any source, rather than rely on a long file mapping ros index names to os-specific package index names.
      • Note that Nix packages can’t currently be published directly to nix-ros-overlay, so they need to be built and released to the ros package index with standard tooling.
    • Significantly less effort is needed to spend ensuring each ROS release corresponds to specific versions of Ubuntu with specific packages versions that can be depended on. This is because ROS packages built with Nix can directly specify commits of nixpkgs to depend on, with their desired package versions.
  • More standardized tooling
    • While Nix documentation is very far from “good,” it has more comprehensive documentation than a lot of ROS tooling, and is improving.
  • No need for containerization
    • Since nix packages can be installed and built reproducibly on any system that runs Nix (Linux and MacOS natively, Windows with WSL), there’s no reason to stuff all your ROS tooling and projects into a docker container, which seems to be the approach favored by a lot of ROS projects.

In the interest of fair discussion, there are some notable drawbacks I can think of:

  • Nix files, unlike package.xml, are written in a (relatively simple) turing complete DSL. Although this can be managed by templates, it definitely spooks developers in the same way someone who only learned python might be horrified by cmake.
  • Nix flakes, a standard that is pretty essential to using and distributing reproducible packages, along with a better CLI, have been “experimental” since 2021, despite a large portion of the Nix ecosystem depending on their functionality. There seems to be a lot of this kind of weird drama within the nix community.
  • The ROS ecosystem does not currently use Nix
    • This is pretty straightforward; no one likes change or being forced to learn something new.

I believe the benefits of using Nix for building and packaging projects within the ROS ecosystem outweigh the drawbacks, and that it should be a topic of discussion, but am curious what others think.

3 Likes
2

I think that the concepts promoted by Nix have a lot of potential to improve how packaging for ROS is done and the usability of it all. I don’t know enough about Nix itself to say whether it’s a viable tool for achieving that or not, but being not maintained by us is a big bonus, and it’s always better to use an existing tool when it meets the needs rather than build our own (something that was unfortunately not the case when ROS adopted colcon).

I think that this might be missing an important concept of ament-cmake: it doesn’t just provide macros for specifying dependencies, but also things important in ROS such as declaring messages provided by a package and ensuring message source code is automatically generated from the IDL files. Like a great deal of large projects that use CMake, ROS has produced its own set of CMake macros to make the cmakelists.txt files easier to write. Nix may be able to replace the work done by colcon, but I don’t think it can replace everything that ament-cmake provides.

2 Likes
3

Thank you for the response. I appreciate interest in future improvements to ROS infrastructure. Regarding ament-cmake - it appears I misunderstood what its functionality was.

I looked into the source code more and the way nix-ros-overlay currently builds ament-cmake (and catkin) packages is by calling a setup hook for each build tool in the build-ros-package function.

4

Nix, especially Nix flakes, has great potential (except that infamous Nix DSL) for robotic applications. The open-source drama part is not good, though. However, ROS has considerable historical baggage and technical debt before moving forward in such a direction. I don’t think it is impossible, but a few decisive steps have to be taken, such as:

  1. Abandoning current ROS leadership (they reached EOL)
  2. Abandoning the workspace concept
  3. Abandoning the ROS distro concept
  4. Embracing language-specific build and distribution practices (PyPI for Python, cargo for Rust, etc.)
  5. Embracing open standards (e.g. Linux UAPI-style configuration, REUSE) and a cloud-native mindset (e.g. repo-centric dependencies)

Since people here would fiercely oppose these items, the path forward for ROS seems blocked. Some people think rmw_zenoh would save their project, but the problem is rooted much deeper indeed. Alternatively, the easier path is to adopt Zenoh directly. Zenoh proves that robotic applications can be built using multiple languages and standard tooling. It is just like using another library in your favorite programming language without any special voodoo. I hope it will stay like that. Currently, it lacks a launch orchestration system, but we are experimenting with systemd and quadlets.

Then experimenting with Nix or Bazel on this green field may be more interesting than resurrecting the dead horse. The future is exciting.

5

My original post intended to start a technical discussion on the topic of using Nix in ROS. Notably, saying the current ROS leadership, “reached EOL,” is not conducive to this goal. You’re free to address perceived social issues with the project elsewhere, but I ask you to stay civil within this thread. Although, if you have given up hope on the future of the ROS project, I must ask why you’re posting here.

To the actual discussion:

This is an interesting idea, but it is juxtaposed with using Nix for dependency management. Using exclusively language-specific distribution practices means packages have, with exceptions, no way of cross depending on each other or reproducibly being built. In fact, one stated goal of the Nix project is to eventually replace language-specific package managers, since they only exist because general packaging isn’t good enough. One major strength of ROS is that it provides an ecosystem where packages from different languages can be used together.

I touched on this in the original post, but containers are a pretty pointless additional layer of complexity in robotics, since their biggest selling point is easy distribution and isolation from the host system. That is only a major benefit if you need to isolate your packages’ dependencies from the home system, which is the case when you aren’t using Nix.

Working on multiple packages in the same repository is often a good idea. Cargo, for example, supports workspaces where you can build and work on multiple rust packages at the same time. Keeping everything in separate repositories is a recipe for very sad developers. I think the colcon docs make colcon workspaces seem very complicated when afaik they’re just adding everything in the workspace build directory to $PATH in the current shell (overlays being doing that twice). Nix is flexible enough to support building a workspace as a flake, and each package as a flake, or the workspace as a flake including each package (it’s lazily evaluated so you aren’t building the packages you don’t need).

It makes sense ROS distros currently exist to provide a common base of packages that packages can depend on, but nix kind of solves this. In the suggested package management system, distros could feasibly be replaced with hard version breaks, although the only difference in nix-land is ros/ros-2.20 vs ros/ros-2-nixy-notoemys.

Aside regarding your work with Zenoh:

This is pretty cool, although it constrains your project to only run on Linux, which I don’t believe is an option for ROS. For Zenoh, I’d recommend not using quadlets and using systemd services directly or wrapping them with centralized configuration that can be version controlled. The disadvantage of quadlets is that you need to containerize all running code, which is additional complexity, despite containers in robotics mostly being a crutch for bad package management.

I’m not too familiar with Zenoh or DDS to compare their advantages or disadvantageous, but keep in mind Zenoh is replacing DDS, not the entirety of ROS. Could ROS tooling do less? Yes! Even a member of ROS leadership responded to the thread saying Nix not being maintained by OSRF/community is a positive. Approaching flaws with the ROS ecosystem and tooling with the mindset of burning everything to the ground and starting over is not only unproductive, but also prevents your work on a replacement from actually learning from the designs within ROS in a constructive way (see. language-specific package managers don’t solve the same issues colcon/nix are intended to solve).

9 Likes
6

I’m still wondering where did this strive for reproducible builds come from. There’s nothing like that in the long run. Git repos come and go, pip packages come and go, pytorch doesn’t work on too new and too old hardware or drivers… What value is a reproducible build when its inputs are not available or its outputs cannot be run?

Also, I think the ideas presented here tackle the problems from the package builder/devops side, but completely omit “normal” users. One of the great benefits of ROS 1 was that it has set a pretty straightforward environment in which people could experiment and learn. “Do you want to learn ROS? Install Ubuntu xy and develop on c++ or python in their base system versions.” There’s a lot of magic around this simplicity (however strangling it is for more professional users). Too many options is rarely good for newcomers. But this could probably be mostly solved by docs.

My personal experience with outdated research code is that it rarely has a sane package.xml . Do why do you think nix would make this any better. Researchers want to write code, not makefiles.

Last, I’d actually wonder if it were easy to convert all of ROS to nix. When I see how much patchwork needs to be done to build a subset of ROS on the somewhat similar Conda…

2 Likes
7

You’re right that reproducible builds don’t matter for everyone. Most people could probably care less if their code builds a few years. However, they really matter when you want everyone on your team to have identical environments (containers also solve this), or if your deployments to an arm64 car need to be identical to the version of code you just tested on your x64 computer. They also really matter when you want to use a cool ros package from 201X that isn’t actively being maintained. The entire point of ROS is letting roboticists use each others’ software, so it seems sensible that the system for distributing this code be as resilient as possible. While it is true that you can’t always rely on repositories existing, Nix (in fairness, Conda too) eliminates an entire category of dependency matching issues that existing ROS tooling currently ignores.

I personally never used ROS 1, so I can’t speak to its ease of use. However, I don’t believe a Nix based build system (with templates) would be more difficult to use than the existing ros2 pkg create ... + adding a few package names to CMakeLists.txt and package.xml and getting to work. They’d likely work very similarly, only the template would include a flake.nix instead of package.xml.

Lastly, the reason I linked nix-ros-overlay is because it’s a working example that converts existing ROS distributions (and all the packages within them) into overlays to be used in nix, and distributes them all as a single flake (self contained nix expression with pinned dependencies). It’s not too complex internally - just autogenerated functions that call a function to handle building with ament-cmake or catkin. This demonstrates that it’s pretty easy to continue using the existing ROS package format from within a nix-based project.

8

I’m always interested to learn about new ideas concepts etc. But easy of initial use is really important.

I did not attempt yet, but can you give an example how I can create a workspace (or something) were I can run rclcpp_tutorials talker and rclpy_tutorials listener from this repo?

Currenly I would do this (with ROS already installed):

mkdir src
git clone https://github.com/ros2/tutorials src/tutorials
source /opt/ros/jazzy/setup.bash
rosdep update && rosdep install -r --from-paths .
colcon build
ros2 run etc...

To be fair, I had to sneak in a -r for rosdep because there is an issue already :smile:

1 Like
9

The following is hypothetical, and cannot actually be replicated on the tutorials repository because it is not built as a nix flake. I started working on an example for building a full ros project with nix instead of colcon and rosdep, but I believe I’ll have to make a few changes to nix-ros-overlay, since it currently doesn’t export any building functions, only packages (this may take a bit because I’m learning as I go).

Since nix doesn’t have any explicit notion of workspaces, the examples repo is a bit more annoying to use in the exact way you described. Nix recognizes any version controlled repository with a flake.nix at the root level as a “flake” (package with version controlled dependencies), so the ideal way to set up a project with multiple subprojects would either be having a flake.nix in the root directory and default.nix containing a build functions in each subproject or having a flake.nix in the root directory that depends on a flake.nix in each subproject. The difference between these approaches is where your dependency versions are being locked, and I don’t have a strong opinion on which is more appropriate here.

If the project were to be restructured so that a flake.nix was in the base directory and each subproject had a function describing how to build them, the setup would look something like:

git clone https://github.com/ros2/tutorials
cd tutorials
nix build
source result/setup.bash
ros2 run ...

To instead build only rclc examples, you could run nix build .#rclc_tutorials, and the output would be used identically.

Note that the example would require nix (and ros) to be installed. A cool thing you could do is run nix develop, which would provide you a shell with all necessary dependencies to build the project, including the ros2 cli. This means you could then run the demo without previously installing ros on your system.

These structural differences regarding workspaces do have the effect of preventing users from being able to just clone arbitrary examples or packages into their projects. To achieve exact parity with your example (cloning into src of an existing workspace), a few lines of code would have to be added to the base project (src/../flake.nix):

{
    # ...
    inputs.tutorials.url = "path:./tutorials";

    # inside output function
        packages.examples = examples.defaultPackage."<arch>";
}

This is very rough since it would be modifying an existing flake, but all these would be doing is “forwarding” the inputs flake to be an output of the project-level one.

10

The best way to think about workspaces that colcon operates on is similer to Python and Ruby virtual environments (such as those created by the Python venv module), but without the isolation from system-installed non-core libraries that those virtual environments typically include.

If nix cannot provide this by default, then to use nix we would likely need to either find something else to go alongside nix and provide that virtual environment capability (without being as heavy as a Docker container), or provide some kind of wrapper - which would reintroduce some of the often-stated disadvantages of using colcon.

11

@AngleSideAngle I have been working to integrate the work done by @lopsided98 back upstream. (see here: Merge NixOS support from lopsided98 by robwoolley · Pull Request #306 · ros-infrastructure/superflore )

He gave me his approval and I hope to get it reviewed and merged shortly. The superflore tool generates the recipes that you see in nix-ros-overlay. (You can see him running it in the GitHub Actions: Workflow runs · lopsided98/nix-ros-overlay )

I am not a Nix OS developer myself, but I am the maintainer of the superflore tool. I would love to get others involved as any improvements for Nix would likely benefit OpenEmbedded and Gentoo as well.

I look forward to hearing your thoughts.

Regards,
Rob

1 Like
12

This is the coolest part about nix! Every unique package that you build is stored in /nix/store/<hash>-<packagename>-<version>, similarly to how docker will cache every image you download. Everything in the nix store is easy to clear out and not “installed” on the main system. For example, if I were to run nix develop inside a flake that depends on foo, the command will build/download foo, placing it into /nix/store/abcdefg1234-foo-1.0.0 and then enter an ephemeral shell environment (similar to python’s venv) where the foo binary located in /nix/store/abcdefg1234-foo-1.0.0/bin/foo is on $PATH. Upon exiting the shell, foo is just cached in the nix store and “doesn’t exist” on the home system. These unofficial docs explain the nix store in more depth.

@robwoolley thanks for your effort, it would be very cool to be to officially generate nix package definitions from the ros index. This is also helpful because I was just combing through the source code, trying to find the script that generated the package definitions… That, along with some official examples (I’d be willing to work on them), would definitely make using nix to wrap colcon/existing ros infra in a project practical. I believe this is what clearpath does based on looking at some of their repositories. However, the more ambitious (and breaking) idea I initially suggested was replacing the infra with nix in the first place.

13

That is a bummer. We depend on multiple open source repositories which are not under our control and not released to the buildfarm.
Maintaining a fork just to put a flake.nix in there seems a bit much :frowning: .

Typically all changes we make, we open up a PR for it. But I don’t think all maintainers will accept a flake.nix file (just yet).

14

Thanks for starting the discussion!

As an happy user of ROS via another user-space distribution/package manager different from apt (conda/pixi + RoboStack) it is always nice to see user interest on these topics. To complete the collection I expected that at some point somebody worked on compiling ROS on top of spack, but I guess there is not enough intersection between spack users and ROS/robotics users.

For example, nix-ros-overlay can wrap ament-cmake, but projects written with nix can get away with using standard cmake for building their C++.

I think that separating ament-cmake and standard cmake package as if they needed different tools is unfortunately a common misconception, but ROS C++ packages are indeed standard cmake packages, exactly like ROS Python packages are standard Python packages. The only difference is that they use some CMake macros from the ament_cmake project, a bit like KDE projects use macros from the ECM project. However, there is nothing “special” in them, you can install them via the usual cmake -Bbuild && cmake --build buid && cmake --install build commands. From my point of view, the main difference between most ROS repository and the rest of the C++ world is that in most non-ROS world, each repository have a CMakeLists.txt at the root, while it is not common to have a single repository with many directories each with its own, as it would be a bit complex to build with tooling like colcon. In the past I had the need to ensure that a ROS-style C++ repository could be built as a single CMake project, and I came up with the workaround with this PR Add support for building the whole repo as a single CMake project by traversaro · Pull Request #27 · icub-tech-iit/xcub-moveit2 · GitHub, that works fine even if it is not particuarly scalable.

Projects like vcstool and rosdep are replaced by a more programmatic solution, since Nix derivations deterministically properly handle dependencies from any source, rather than rely on a long file mapping ros index names to os-specific package index names.

I am a bit confused by this point. As far as I see, nix recipes contain a list of dependencies (see nix-ros-overlay/distros/humble/hri-rviz/default.nix at 31f07eb092fd7f9ee56f03108aeb0b89e5a89b91 · lopsided98/nix-ros-overlay · GitHub) exactly like a package.xml contains a list of rosdep keys. Why would you prefer that ros packages maintained a list of packages specific to a single distribution (nixpkgs), instead of mantaing metadata that can be used on a wide range of distributions?

Significantly less effort is needed to spend ensuring each ROS release corresponds to specific versions of Ubuntu with specific packages versions that can be depended on. This is because ROS packages built with Nix can directly specify commits of nixpkgs to depend on, with their desired package versions.

I am a big fan of lockfiles for reproducibility, but I think that using lockfiles on the top of a rolling relase distribution (be it conda-forge, nixpkgs master or pypi) is a bit different from using a stable distribution (like a Ubuntu or RHEL). When you use lockfiles, you get reproducibility, but you do not have (in general) of just get security updates for your dependencies, that instead is typically what stable linux distributions guarantees (even for a long time, if you are willing to pay for it: https://ubuntu.com/robotics/ros-esm). I guess nixpkgs release-YY.MM may provide something similar, but I do not know enough about it.

That is a bummer. We depend on multiple open source repositories which are not under our control and not released to the buildfarm.

Yes, I think being able to support arbitrary C++ or Python repository is really a great feature of colcon. In the past I suggested to use colcon to teams that were using C++ completely outside of the ROS world, and they are quite happy happy with that especially as it was not necessary to modify at all the projects that they were building, as opposed to other approaches like bazel or (to a lesser extent) CMake’s FetchContent.

That, along with some official examples (I’d be willing to work on them), would definitely make using nix to wrap colcon/existing ros infra in a project practical.

I think this is really interesting! On the conda side we have a similar problem, as rosdep supports quite naturally any package manager in which packages are installed via <package-manager-tool> install package1 package2 ... (such as conda), but it is less obvious how to integrate with project-oriented package managers such as pixi, in which the list of packages to install is stored in a sort of project manifest file committed to the repo (flake.nix for Nix flakes or pixi.toml for pixi projects).

For projects that basically build a colcon workspace, I think it would be cool to have some way to ensure that the project manifest is kept in sync with the information from the package.xml of each project in the colcon workspace, but I never looked to deep in that direction.

3 Likes
15

Always happy to have random technical discussions on the internet :)

Building a project with nix does not require nix-related files inside the project - the way nixpkgs works is by having derivations inside the NixOS/nixpkgs repository download a specific commit of a package’s source and build it from source (or just download and untar a binary, in the case of proprietary software). It’s usually pretty straightforward to do this.

I had some fun properly looking into these (never heard of pixi before), they seem pretty cool, aside from past biases born out of spending way too much time fixing friends’ conda environments /j. Conda packaging (especially with pixi environments) seem to have roughly similar advantages to Nix, without the same reproducibility guarantees and more focus on binary distribution than building from source. Both have pretty straightforward advantages over the current ROS build and distribution tooling.

I appear to have fallen for this misconception… Admittedly, I’m not familiar with CMake beyond searching stackoverflow.

Yes, Nix expressions require you to specify the dependencies to build a project with. To better articulate the point I was trying to make, in order for rosdep to figure out how to install a package (pip, apt, dnf, etc) and what the package’s name will be, it utilizes a 10000 line long yaml file listing a bunch of common linux packages and their varying names. This is a necessary evil in order to have ros run on “any” linux distribution, but not a programmatic solution.

Building a ROS project involves three types of dependencies: distro/pypi packages installed through rosdep, ros index dependencies installed and built by rosdep, and random source which colcon may have no idea what to do with. There’s no systematic and uniform way of dealing with the dependencies that are “off the beaten path.”

vcstool is relevant because nix provides various functions to fetch source code from the internet, where they can be built the same way as your actual source code. Nix provides a more straightforward way of integrating external dependencies into your build instead of having a separate workspace/build steps for how to build vcstool repos (or a bunch of submodules).

I was making the argument that ROS should distribute its packages through nix, as opposed to the custom system currently using rosdep, superflore, and package.xml files. The way nix-ros-overlay currently uses a modified (potentially upstreamed!) version of superflore to generate nix definitions is analogous to what could be done by parsing each package’s expression if ros distributions were built using nix.

Aside from rolling vs stable, nix’ packaging model is especially not tuned towards security patching applications because security patches on the same version would break reproducibility. This drawback is also a positive, since nix requiring identical source to build the same version of a package is strong protection against supply-chain attacks.

I’m not going to pretend some hacks you can do with nix compare to an actual security team at Canonical… but a skilled user can override the nixpkgs version a package/flake and use overlays to cherry pick security patches. I’m not aware of companies that do this for nix in the same way, but it is possible.

I don’t know if pixi project configs support any scripting, but it probably wouldn’t be terrible to parse the dependencies section of a project’s packages.xml. This could definitely be done with nix.

2 Likes
16

Ok, I think my point of confusion is here. Just to be aligned argument/proposal is to (I am not sure I got it correctly, that is why I am asking):

  • Drop the support for building ROS against any other source of dependencies except for nixpkgs (so no apt, no dnf, no conda, no Windows support without WSL, no yocto, no gentoo)
  • As multiple package managers would not be a requirement anymore, at that point one could remove the package.xml files and “just” list nix dependencies in nix flake files packages instead of rosdep keys contained.
  • For the similar reason, drop bloom and superflore as it would not be necessary to generate nix config files anymore, as they would be already in the repos, in place of package.xml

Is that correct, or I misunderstood something?

Just to clarify, the rosdep abstraction is that enabled ros to be brought on nix and (from what I understood) powers rox-nix-overlay, see Add support for Nix/NixOS by lopsided98 · Pull Request #697 · ros-infrastructure/rosdep · GitHub and Code search results · GitHub .

17

You are new to this forum. This is not how it works here.

I would definitely love to see pure Nix-based packaging for robotic applications, and it would complement containers for sure. But you can see the first reply from the CTO @gbiggs was preaching how important ament-cmake is for ROS and presenting it as an obstacle. Still, later, we learn in the following messages that it is just a regular set of cmake macros without any extraordinary power, and colcon is just for convenience. Of course, Nix or Bazel can handle all of them. Anyway, most of that stuff maintains archaic workspace features (overlay/underlay/env-vars-- poor man’s containers), so they do not contribute to a modern development environment.

You would not have had the technical discussion you wanted here without my response (you are welcome). Otherwise, you would get either radio silence or someone suggesting ament-nix package or colcon nix verb and how special ROS has been. So I am happy that you have succeeded in getting a proper discussion.

P.S. Containers are our friends. ROS would have been designed differently if they were available/widespread in 2007.

1 Like
18

@doganulus you’ve been preaching purity in build systems a few years already. Have you already come with a complete proposal that would be both pure, practical and substitute all concepts currently needed by ROS?

The “preaching” Geoff did in this thread is a simple explanation of context to people who may not see the whole picture.

You can take a look at it from the other side - you have a CTO directly responding to users in a forum!

6 Likes
19

So if I collect 10 random research packages built with the hypothetical NixROS and put them in a single workspace to combine their capabilities, I’ll end up with 10 different versions of GCC (which I’ll need to build from source), 10 different versions of Boost, 10 different versions of rclcpp etc.? How is this supposed to scale? How is this supposed to be interoperable? How the heck would anyone certify and secure that?

Conda chooses the way that everything has to work with the latest version of everything else. Which brings extreme maintenance burden. But it allows updates and allows having a single version of each package.

1 Like
20 
$ rosdep install timemachine

ERROR: Rosdep cannot find all required resources to answer your query
Missing resource timemachine
1 Like