dotfiles VS jsonnet

Not sure about central but just search dotfiles, config, or flake on GitHub and filter by nix language. Most dotfiles are a sort of “distro” as nix let’s you configure everything from scratch in a central way. Eg my personal dotfiles are an abstracted layer of NixOS/home manager. This can be seen honestly in a lot of popular configs. Eg my WireGuard module turns high level options into automatic configs (see: module).

What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.

The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs used libraries) and is extremely difficult to approach and understand.

[1]: https://github.com/jordanisaacs/dotfiles

Not entirely sure what you mean by policies. But you can use rycee’s buildFirefoxXpiAddon. All you need is the xpi. See: https://github.com/jordanisaacs/dotfiles/blob/master/modules/users/graphical/applications/firefox.nix for some manual packages.

As a heads up setting up gnome-keyring is an adventure in and of itself when not using GNOME which from the sounds of it you are not. It took me a month of on and off trial and error to finally quash the last of its bugs. You can search around my dotfiles where I have it working but the solutions are all over the place (modules/system/gnome/default.nix, modules/users/graphical/shared.nix, and modules/users/graphical/wayland.nix).

I’ll just add on, I use functions in my nix file to make configs (iso, home manager, nixos),: function folder. With this logic you can create basic other hosts. How they are used in used in flake.nix

I am using this repo as a guide. I created a module which has the bootloader and filesystems configuration, and here I would like to conditionally load the qemu guest configuration, based on a configured attr. When you install NixOS in a qemu vm, this import is automatically added by nixos-generate-config to /etc/nixos/hardware-configuration.nix like so:

jsonnet[1] and kapitan[2] are the tools I currently use. Their learning curve is not optimal (and I tried to contribute to smoothen it with a jsonnet course[3] and a 'get started wit kapitan' blog post[4]), but once used to it it's hard to do without, and their combination makes them even more useful (esp. if you deploy K8s).

In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configured with json in addition to HCL. But that would have been less fun I guess ;-)

I hope for Ruud it finds its niche, there's quite some competition in this field!

1: https://jsonnet.org/

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure:

https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7...

Now consider 100s (if not 1000s) of such files.

I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentation -- since YAML is indentation sensitive) is easily beat by any of:

- https://jsonnet.org/

- https://nickel-lang.org/

- https://nixos.org/manual/nix/stable/language/index.html

- https://dhall-lang.org/

- (insert many more here, probably including Pkl)

jsonnet cli: link

Jsonnet: A data template language implemented in C++, suitable for application and tool developers, can generate configuration data and organize, simplify and manage large configurations without side effects.

[Language: Jsonnet] (on GitHub)

Maybe you'd like jsonnet: https://jsonnet.org/

I find it particularly useful for configurations that often have repeated boilerplate, like ansible playbooks or deploying a bunch of "similar-but" services to kubernetes (with https://tanka.dev).

Dhall is also quite interesting, with some tradeoffs: https://dhall-lang.org/

A few years ago I did a small comparison by re-implementing one of my simpler ansible playbooks: https://github.com/retzkek/ansible-dhall-jsonnet

Apologies for the lack of context, and for missing this comment until today.

Both are tools for defining kubernetes manifests (which are YAML) in a reusable manner.

Jsonnet is a formally specified extension of JSON. It’s essentially a functional programming language (w/some object oriented features) that generates config files in JSON/YAML/etc, so it’s straightforward to determine whether an input file is valid, and to throw an error that points to an exact line if it’s not. It has a high learning curve, especially for people whose only experience is with imperative languages.

https://jsonnet.org/

Helm charts also generate YAML/JSON config files, but they use Go templating. This is easier and faster to understand, since it’s mostly string substitution and not much logic (there’s conditionals, iterators, and very basic helper functions). Unfortunately a simple typo or mistake can cause errors that are difficult to diagnose (the message may indicate a problem far away in code from the actual mistake). It can also generate output that’s valid according to the string templating rules, but not what was intended, which can be very confusing to debug.

Despite these shortcomings, the vast majority of kubernetes applications are distributed as helm charts. I understand why things ended up this way, but I still wish it were more common for people to invest the upfront effort to learn the superior tool, so it could be more widespread.

I like Google's Jsonnet [1], which has all of this except for 4.

Jsonnet is quite mature, with fairly wide language adoption, and has the benefit of supporting expressions, including conditionals, arithmetic, as well as being able to define reusable blocks inside function definitions or external files.

It's not suitable as a serialization format, but great for config. It's popular in some circles, but I'm sad that it has not reached wider adoption.

[1] https://jsonnet.org/