Building NixOS using Nixtamal

9 points by toastal

rprospero

I feel like I'm missing something, because I'm not understanding the benefit here. The big selling points that I saw were

The nix configuration can be stored in source control. While that's true, hasn't it always been true? I had my nix configuration under source control back in 2016, before flakes even existed.
The inputs are pinned. This is certainly better than channels, but I've seen a dozen different systems for pinning inputs, flakes included.
Nixtamal doesn't use "experimental" features. Perhaps it's because I'm an experimentalist, but that doesn't scare me. The flakes features might change or disappear, just like the print statement in Python, but that didn't make Python 2 "experimental".

Looking a bit deeper, I'm also slightly concerned that KDL is the configuration language when it is one of the few config languages not supported in pkgs.format. Similarly, nixtamal offers to be VCS-agnostic, but my current flake pulls from GitHub, SourceHut, some stranger's web server, and my own NAS unit. I even have inputs that aren't git repos, though having first class Darcs and Pijul support does seem kind of cool.

I'm not exactly a partisan in this fight. I'm happy to switch off flakes if I'm offered something better. After all, I switched to flakes because it was a more convenient than what I had before. I'm just failing to understand what is being offered here.

toastal
This post is a reaction to the 3rd person asking me for patterns on how to use Nixtamal with NixOS configurations—specifically those coming from flakes looking to adopt system.nix + overlays. The cookbook is for patterns with the input pinner.
1. Yep, I have as well… but I have seen many places that if you are using a configuration.nix file, it’s you can’t put it it version control (which is almost certainly why the Nixmap project shows as much)
2. Yes. there are several input pinners—I made a comparison table to the best of by knowledge of the common ones. None check all boxes.
3. Flakes aren’t stable. The API has drifted, the manifest has no version, & there are 3 different flake implementations now (NixCpp, Lix, Determinate Nix). Folks are free to try them out, but a) they shouldn’t act like it’s stable b) without much effort you can get backwards compatibility without adding dependencies if using the patterns here. I was wanting to get a piece out that showed these patterns on how a stable Nix system would be consuming projects to help both system.nix adopters & upstream project think about compatibility (slapping flake-compat isn’t the right solution).
The goal isn’t to consume or generate manifest files from Nix so probably not a huge issue, but there is a KDL feature request & a pull request. KDL is used in Zellij, Niri, Miso, & even the System76 scheduler to name a few.

I'm happy to switch off flakes if I'm offered something better.

That would be the goal, but Nixtamal only handles inputs. You’d need another project such as Nilla (not affiliated, not an endorsement) if you want the schema side. The problem is baking this buggy kitchen sink into the binary means its a) hard to iterate & b) hard for competition when folks say an experimental feature they can flip on. There are some neat ideas out there—& the ones that aren’t flakes all tend to be pluggable, but flakes owning a project in the way folks use it it practice, make it very difficult or impossible or expensive to get what could/should otherwise be classic Nix expressions. This ends up leading to tight coupling that’s hard to use at scale which leaves a sour taste in folks’ mouth about Nix. A lot of $BIG_TECH, even when using flakes set flake = false; on all inputs to get back control & lower complexity which also requires stable-friendly code.

(I’m also proud of handcoding up all the stuff to get Asciinema + Webm (AV1) video + GIF fallbacks for <noscript>… it was a lot of things to learn & plumb)
- rprospero
  
  Thank you for your thoughtful reply, especially to a comment which was bordering on unkind. With the added context, I think I understand a bit better what you're accomplishing. I'll be keeping an eye on this project, because it looks like you've solved a problem that I will encounter, even though I haven't.
  
  As a side note, I'm using and loving Niri, which is why I'm painfully aware of the issues keeping my KDL config file linked up changes to my home-manager config. I'm hoping that the sodiboo gets more time this coming December to finish that PR.
  - toastal
    
    KDL is pretty neat since it’s one of the only things I have seen that tries to be compatible with both JSON & XML. If they get XSLT-like support the floodgates will be open (which is why I have avoided forge-specific code paths in the binary since this is ideal layer to be putting this sort of thing as a ‘macro’—keeping the binary leaner, easier to maintain, & also pushes me in a direction to be generic at all time so anything could be supported). It’s not fast, but there has been steady KDL adoption so we will see.
- tuxes
  Nice table.
  
  I have wanted a few features for a while:
  
  "Patch support", so I can deploy my nixpkgs PRs without having to keep a fork that I then have to update.
  
  "Signing verification", so I can have one trusted machine do the version bumps, and have other machines deploy from that.
  
  I'm glad to see projects supporting this!
  - toastal
    
    "Patch support", so I can deploy my nixpkgs PRs without having to keep a fork that I then have to update.
    
    This (+ Darcs / Pijul support) was one of the primary motivators to create the project. Nixpkgs in particular has 2 good reasons: a) as you mentioned maintaining a fork is cumbersome (or worse pulling multiple copies of Nixpkgs just for a 5-line diff), b) I’m now more willing than ever to at least publish my changes upstream vs. hoarding them locally to get stuff working which helps everyone. But I also found myself using patches like in the cookbook post here with other upstream projects—which has let me be a lot more patient with review since I can use the code now.
    
    Signing verification
    
    The default fetcher behavior is to strip the VCS metadata as it usually isn’t needed which is often a method to testing the signing. I don’t have it yet since I don’t know how I want to handle this aspect (& Darcs doesn’t even offer signing of patches, just signing before email).