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.