nix-ros-overlay
rfcs
Our great sponsors
nix-ros-overlay | rfcs | |
---|---|---|
3 | 46 | |
158 | 476 | |
- | 6.3% | |
9.0 | 5.0 | |
5 days ago | 2 days ago | |
Nix | ||
Apache License 2.0 | Creative Commons Attribution Share Alike 4.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
nix-ros-overlay
- tell me one thing you don't like about ROS
-
Nix is the ultimate DevOps toolkit
Thanks for the response!
> This is difficult to answer without knowing more details.
The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:
https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...
The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.
Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...
Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to users and any system which required everyone to leave behind these existing workflows would be an immediate non-starter.
I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build packages as usual with colcon, the usual workspace-building tool, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.
[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay
rfcs
-
Build System Schism: The Curse of Meta Build Systems
Nix with dynamic derivations (RFC92) could potentially beat this curse.
https://github.com/NixOS/rfcs/blob/master/rfcs/0092-plan-dyn...
-
Show HN: Flox 1.0 – Open-source dev env as code with Nix
See: A plan to stabilize the new CLI and Flakes incrementally https://github.com/NixOS/rfcs/pull/136
- RSS can be used to distribute all sorts of information
-
I like gentoo's package deprecation process
NixOS recently introduced "problem" infrastructure to deal with such problems more gracefully and explicitly:
https://github.com/NixOS/rfcs/blob/master/rfcs/0127-issues-w...
-
NixOS and Flakes Book: An unofficial book for beginners (free)
For some more context: Flawed as they are, Flakes solve a large number of problems Nix experiences without them. This is why I, and presumably many others, use them even in their current experimental state.
An RFC was recently accepted to commit to forming a plan towards stabilization of Flakes: https://github.com/NixOS/rfcs/pull/136
Personally, I don't believe there won't be any breaking changes, but I also believe that the stabilization of Flakes is still a ways away and hope that there will be a reasonable migration path.
- NixOS RFC 136 accepted: A plan to stabilize the new CLI and Flakes incrementally
-
Super Colliding Nix Stores: Nix Flakes for Millions of Developers
> Afterwards, Flakes itself and its CLI components can be stabilized. The final design of Flakes will also require another RFC.
That seems like Flakes are still quite a ways away.
[1] - https://github.com/NixOS/rfcs/pull/136
First, the non-Flakes CLI wll be stabilized, in phases.
-
Lanzaboote vs. bootspec-secureboot
Both require the Bootspec patches, only support systemd-boot, have recent activity, and include a Rust-based tool for signing images.
-
Using NixOS as a Hypervisor for a k3s Cluster in Homelab, can I define the VMs in Nix config?
I just found an RFC for similar that was unfortunately closed back in the day: https://github.com/NixOS/rfcs/pull/12
-
Nix journey part 1: My grand unified theory of Nix documentation · Tinkering
If you'd like to understand, reading through https://github.com/NixOS/rfcs/pull/49 is probably a good place to start.
What are some alternatives?
not-os - An operating system generator, based on NixOS, that, given a config, outputs a small (47 MB), read-only squashfs for a runit-based operating system, with support for iPXE and signed boot.
haskell-nix - Nix and Haskell in production
nixpkgs - Nix Packages collection & NixOS
rosdistro - This repo maintains a lists of repositories for each ROS distribution
spack - A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
nix - Nix, the purely functional package manager
emacs-overlay - Bleeding edge emacs overlay [maintainer=@adisbladis]
nix-1p - A (more or less) one page introduction to Nix, the language.
nix-darwin - nix modules for darwin
nixos-generators - Collection of image builders [maintainer=@Lassulus]
Home Manager using Nix - Manage a user environment using Nix [maintainer=@rycee]
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more