Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Nix-ros-overlay Alternatives
Similar projects and alternatives to nix-ros-overlay
-
distrobox
Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
nix-ros-overlay reviews and mentions
- tell me one thing you don't like about ROS
-
Package override not applying to Nix-shell / Cmake?
I believe this might be due to me also using the ROS overlay for Nix (https://github.com/lopsided98/nix-ros-overlay). Some packages that I'm using from ROS also require PCL, so I suspect that Nix might be ignoring my CUDA-enabled overlay and using the regular PCL package in order to meet the required dependencies. I'm not too sure how to confirm this...
-
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
-
A note from our sponsor - InfluxDB
www.influxdata.com | 10 May 2024
Stats
lopsided98/nix-ros-overlay is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of nix-ros-overlay is Nix.
Sponsored