[survey] how are you using flakes today?

1

context and survey question

As I am learning to use flakes I’m curious about how you use them.

If you would like to share, do drop a few lines here about what you are using flakes for, what it has felt like adopting them, etc.

my experience

I migrated an internal project’s CI infrastracture from Docker to nix, embracing flakes. Our jobs execute much faster! The overall experience has been pleasant. While using nix 2.4.x puts me in the “experimental” group, nix flakes has felt quite stable for this use case.

2 Likes
2

We migrated all of our company projects (100.000 loc of ci/cd code and 850.000 loc of business logic) from:

  • Docker to bash scripts with deps provided by nix-shell
  • Then to nix-build 2.3 with sandbox disabled
  • By this time we had reduced pipeline times by a LOT and increased developer productivity and happiness by thousands percent. They could launch developer environments and fully featured local web servers with one command
  • And finally to nix-build with flakes and sandbox disabled. It was at this point that I realized I made a mistake: teaching other colleagues to maintain the Flakes codebase (devops people from a non-nix background and Debian-like OSes) was hard as there is not enough documentation. Also some bugs in the Nix-unstable binary itself started to appear and we confirmed those bugs not to appear when building the same thing from Nix stable. This was just too much, as we chose Nix initially trying to escape the Docker way of doing stuff (unreliable, non-reproducible, non-cacheable, non-granular, even insecure sometimes)
  • So we invested a lot of effort and got back into nix-build 2.3 but this time with sandbox enabled (a.k.a. finally pure!!). Packaging in a pure way dependencies from python-pypi/ruby-gems/npm and a few less known languages was the hard part
  • We open sourced Makes GitHub - fluidattacks/makes: A software supply chain framework powered by Nix.
    with all of our learnings
  • And here we are: a million lines of code running over nix stable (2.3.15) with sandbox enabled, using the Makes Framework

I, in any case, see on Nix Flakes a good thing for the ecosystem. We will just wait until it’s official and stable, with docs, reliable at any scale

That will be soon, right? I hope so!

13 Likes
3

(emphasis mine)

Could you tell more about why disabling sandboxing was necessary? Wouldn’t it have prevented the build bugs1? (Or did I misinterpret something, and your next item actually says that you kept using flakes but enabled sandboxing this time around?)

I have yet to learn flakes, but none of the online resources I have found2 mention issues or caveats regarding sandboxing. That is, I just learned that sandboxing is disabled by default, so no wonder they didn’t bother, as it would have made the text more complex. Tried looking up “nix flakes sandbox enabled” but couldn’t find much (probably because I couldn’t decide from the issue/post titles whether they are actually related to Nix flakes).

[1]: … and beyond (couldn’t resist…)

[2]: These:

4

Sandbox is an option (--option) you can pass to nix-build and other commands, it exists on:

  • Nix 2.3 (stable)
  • Nix 2.4 (unstable)
  • Nix 2.4 (unstable) with Flakes support (a.k.a. passing --experimental-features flakes) (Sometimes they call this Nix 3.0)

Sandbox is pretty much the core reason why Nix is so awesome. Sandbox allows you to build derivations in an empty file system, without access to the internet, and on a perfectly empty environment, so pretty much it ensures the build step is a pure function without side effects or visibility to the outside world

According to the Nix manual:

The default is true on Linux and false on all other platforms.

The link you sent, is for nixpkgs, not nix. Sandbox is a feature of Nix, that is disabled/enabled on Nixpkgs for achieving pure builds

Could you tell more about why disabling sandboxing was necessary?

It was not necessary, but it was very convenient back then

Let’s start from the context that our first iteration was migrating from Docker to writing “bash scripts with dependencies provided by nix-shell”. On our next iteration we wanted to benefit from the cacheability of nix-build, but we found it very hard to make our existing packaging run on a restricted environment with the sandbox. (How to do a pip/npm/ruby-gem install if you don’t have access to the internet). So we decided to use nix-build --option sandbox false --option restrict-eval false in order to grant internet access to derivations, and benefit from the nix-build cache at the trade-off of not being perfectly pure

So again, it was not necessary to disable sandbox, it was just convenient not to spend too much time and effort being perfectly pure. At this point the benefits of using nix-build instead of nix-shell were far greater. Besides code running on nix-builds with sandbox disabled is also more pure than nix-shell, so this was a victory in our context

Wouldn’t it have prevented the build bugs?

No, the bug was directly on the Nix binary and not related to our code, see why:

This is the exact image of the bug:

image
image1500×222 190 KB

file descriptors are finite, here it seems that either Nix is leaking them, or there is no control that avoids opening more than X

This happened on Nix 2.4 (unstable) with flakes support. When building the same from Nix 2.3 (stable) the error did not happen. So this is one of the strong reasons why we downgraded to Nix 2.3 (stable). Stable normally means code has passed through more tests and real usage and more bugs were identified and fixed. You normally want stability on production systems

2 Likes
5

(Sorry for hijacking this thread with the sandboxing topic; these should probably be moved here)

Thank you for the detailed explanation, and this aside made your reasoning instantly click for me; not sure why I didn’t think about it as I have been struggling with npm, Elixir/Erlang’s mix, etc. as well.

Thanks for the clarification! Totally misinterpreted your initial post.

6

I use flakes for everything that I previously used nix stable for: setting up environments and builds for projects and configuring NixOS.

1 Like
7

I’m using them for a few different purposes, but I’m not really proficient enough with them to confidently show too many examples yet:

  • I have packaged a Python application I wrote to control my pandemic-era keylight: https://github.com/waxlamp/elgato/blob/79d5989bf0fb696c3ad4d1c68f82e2ec038eb4de/flake.nix (this is still WIP, and Tom Berek helped me out immensely with this).
  • I don’t have the clout nor the understanding/desire to convert my workplace over to Nix-based workflows, so I plan to use Flakes to maintain development environment setups just for me for the projects I am involved with. This would involve creating github repositories with flakes for setting up the exact environments I need to support the “usual” workflow (i.e., Pipenv, Poetry, or NPM with required system dependencies, so that I can use the same non-Nix workflow my colleagues are using) or in cases where I have more control over the project, adding flakes.nix files directly to the appropriate project codebases.
  • I recently figured out (again with Tom’s help) how to unify my usage of flakes via nix run nixpkgs#<package-I-want-to-try> with my home-manager setup for installing the same packages (i.e. via the same flake source) into my user profile. (If this turns out to be productive I plan to post a topic to discourse to show off what I am doing.)

I am most interested in the improved ergonomics afforded by flakes. However, I often feel as if I must be missing something, because others do not seem as excited about that aspect of flakes. For me, ultimately, I want to have reproducible dev environments for my work and personal projects, and I want to have a reproducible working environment in my computers at large. I see the path to that promised land more clearly through flakes, but I still have much to learn.

I hope this helps.

roni

2 Likes
8

At work, we make heavy usage of flakes to package all of the projects that we deploy or ship. Flakes solved the pinning usage (and replaced previous niv usage), and also solved multitude of different output schemes that we had.

At home, I recently converted my home-manager installation to use flakes, now I don’t have to worry about different channels between my 3 devices which use nixos.

4 Likes