haskell-nix VS rosdistro

Compare haskell-nix vs rosdistro and see what are their differences.


Nix and Haskell in production (by Gabriel439)


This repo maintains a lists of repositories for each ROS distribution (by ros)
Our great sponsors
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
haskell-nix rosdistro
3 4
964 634
- 2.5%
0.2 10.0
5 months ago 1 day ago
Nix Python
- GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.


Posts with mentions or reviews of haskell-nix. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-06-02.


Posts with mentions or reviews of rosdistro. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-05-20.
  • What to do about GPU packages on PyPI?
    7 projects | news.ycombinator.com | 20 May 2021
    The business about mapping from PyPI to system dependencies is an important one, and (having not read the entire thread) I do hope that gets some attention— it's particularly curious that it's been this long and it hasn't, given Python's often-role as a glue language.

    Another example of an ecosystem maintaining mappings out to system packages is ROS and rosdep:


    Now it's interesting because ROS is primarily concerned with supplying a sane build-from-source story, so much of what's in the rosdep "database" is the xxxx-dev packages, but in the case of wheels, it would be more about binary dependencies, and those are auto-discoverable with ldd, shlibdeps, and the like. In Debian (and I assume other distros), the binary so packages are literally the library soname + abi versions, so if you have ldd output, you have the list of exactly what to install.

  • If I use ros2 built from source, can I use "sudo apt install ros-distro-package" to install packages??
    1 project | reddit.com/r/ROS | 13 Apr 2021
    The names you use for the tag (and the other dependency tags in your package.xml) are used by rosdep to figure out what needs to be installed. The name doesn't necessarily correspond to the apt or pip package name, but most of the time it's the same. For example, for matplotlib: https://github.com/ros/rosdistro/blob/24141d9063fddd6eeca7f1db9e721fa8d600c62f/rosdep/python.yaml#L6296
  • Nix is the ultimate DevOps toolkit
    21 projects | news.ycombinator.com | 9 Apr 2021
    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:


    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

  • HUGE ROS Noetic Update -- 93 New and 119 Update Packages
    2 projects | reddit.com/r/robotics | 25 Jan 2021
    Thanks for the feedback. I bumped a couple of the core devs and got the change reverted and it is now merged. It should be in the next Noetic release.

What are some alternatives?

When comparing haskell-nix and rosdistro you can also consider the following projects:

nixpkgs - Nix Packages collection

dh-virtualenv - Python virtualenvs in Debian packages

haskell.nix - Alternative Haskell Infrastructure for Nixpkgs

nix-ros-overlay - ROS overlay for the Nix package manager

nixos-config - Personal collection of NixOS config files

rfcs - The Nix community RFCs

Cabal - Official upstream development repository for Cabal and cabal-install

static-haskell-nix - easily build most Haskell programs into fully static Linux executables

nix - Nix, the purely functional package manager

pndev - CLI tool for es-development

nixos - My NixOS Configurations