Nix is the ultimate DevOps toolkit

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

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
  • nixpkgs

    Nix Packages collection

    I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt

    This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself from version "nix-2.3.10" to "nix-2.3.10-x86_64-unknown-linux-musl" because it saw that package's version string as a version bump. The suggestion in the github issue was to instead use an unofficial third party package for basic package management.

    https://github.com/NixOS/nixpkgs/issues/118481

    The experience came across as a massive red flag and I decided not to pursue it further.

  • aptly

    aptly - Debian repository management tool

    I am very much looking forward to trying Nix I just haven’t made the time.

    That being said the article jogged my memory on some related thoughts...

    If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/

    If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.

  • SonarLint

    Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.

  • asdf

    Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more

    I am very much looking forward to trying Nix I just haven’t made the time.

    That being said the article jogged my memory on some related thoughts...

    If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/

    If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.

  • vaultenv

    Launch processes with Vault secrets in the environment

    > Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.

    Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine.

    You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code.

    Put those tools in your systemd service before launching your app, and you're good to go.

    (NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I won't be able to see the final picture.)

    [1]: https://github.com/channable/vaultenv

  • pndev

    CLI tool for es-development

    We're using Nix packages at Precision Nutrition to manage our dev environments: https://github.com/PrecisionNutrition/pndev/. It's been enormously successful. I highly recommend it.

  • haskell-nix

    Nix and Haskell in production

    I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix

    I hope it helps.

  • rclcpp

    rclcpp (ROS Client Library for C++)

    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

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • rosdistro

    This repo maintains a lists of repositories for each ROS distribution

    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

  • nix-ros-overlay

    ROS overlay for the Nix package manager

    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

  • ros2nix

    Use ROS with the Nix package manager

    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

  • robotnix

    Build Android (AOSP) using Nix

    A few days ago, I came across RobotNix[0] which uses Nix to deterministically build custom Android images. Since I really want to adapt Android to my needs but have always struggled with building Android on my own (what a shitty and complicated build system), I'm now very inclined to learn Nix. I'm not sure I like the syntax but hopefully I'll get used to it.

    Another reason I'm quite excited about Nix is that in my team we're currently using a whole bunch of tools like pip, Conda, npm all at the same time to manage our dependencies and it's starting to become really cumbersome to set up the dev and production environments correctly across operating systems and platforms. For instance, Conda doesn't exist on arm64, lots of pip packages have to be compiled by hand on arm64 etc. etc. It's a mess that I'd love to get rid of.

    [0]: https://github.com/danielfullmer/robotnix/

  • nix-1p

    A (more or less) one page introduction to Nix, the language.

    I wrote a language tutorial for only the language a while back, and have gotten the feedback that it has helped a lot of people - maybe it'd clear something up for you: https://github.com/tazjin/nix-1p

  • nickel

    Better configuration for less

    I think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs.

    [1]: https://github.com/tweag/nickel

  • rfcs

    The Nix community RFCs (by NixOS)

    Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.

    I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn [1]. Given that flakes are a large change, I'd expect (but maybe I am wrong) that there will be a new RFC.

    At any rate, I would be surprised if the new CLI with flakes are close to release.

    [1] https://github.com/NixOS/rfcs/pull/49

  • nix

    Nix, the purely functional package manager

    Yep. The advantage of `with` is that we're dealing with first-class values (attribute sets, like `{ foo = "bar"; }`), rather than an implicit environment/context. My rationale is at https://github.com/NixOS/nix/issues/1361#issuecomment-390420...

    The thing about shadowing is that `with` will not shadow anything that's in the implicit context, which includes things defined by `let` (hence why I avoid it) and function arguments (unavoidable). We can shadow other `with` bindings as much as we like, e.g.

        with { foo = 1; };

  • nix-home

    Nix + HM = <3 (by pwm)

    https://github.com/pwm/nix-home

    The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.

  • nixos

    NixOS Configuration (by pimeys)

    I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines.

    I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away.

    But, I agree, it is REALLY HARD in the beginning to grasp things.

    Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts