vinzenz/zerforschen.plus
0
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

reference-style links do not seem to work

Browse source
This commit is contained in:
Vinzenz Schroeter 2025-04-07 19:42:25 +02:00
parent 889e7d8196
commit f739fdfd3b
1 changed files with 4 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
content/posts/why-i-do-not-use-flake-utils.md
View file

@ -5,11 +5,11 @@ title = 'Why I do not use flake-utils'
tags = ['nix'] tags = ['nix']
+++ +++
I have been using [Nix] for a while now. Around a year ago, I switched everything from the [servicepoint] library to my [machine configuration] over to flakes. I have been using [Nix](https://nixos.org/) for a while now. Around a year ago, I switched everything from the [servicepoint](https://git.berlin.ccc.de/servicepoint/servicepoint) library to my [machine configuration](https://git.berlin.ccc.de/vinzenz/nixos-configuration) over to flakes.
For me the biggest advantage flakes bring is not additional functionality. Instead, they are an easier and semi-standardized way to do what you could before. For me the biggest advantage flakes bring is not additional functionality. Instead, they are an easier and semi-standardized way to do what you could before.
When learning flakes, you often see [flake-utils] being used. With it, you can shorten your flakes by not having to specify everything per system. When learning flakes, you often see [flake-utils]( https://github.com/numtide/flake-utils) being used. With it, you can shorten your flakes by not having to specify everything per system.
### Without anything ### Without anything
@ -92,9 +92,9 @@ While more code can be intimidating for beginners, it actually helps remove a ba
For me, it wasn’t a problem to ignore boilerplate like this at first, slowly learning more language features until I finally understood everything. For me, it wasn’t a problem to ignore boilerplate like this at first, slowly learning more language features until I finally understood everything.
At **[1]**, the supported systems are specified. I personally use `x86_64-linux` and `aarch64-linux`, but I also usually support `x86_64-darwin` and `aarch64-darwin` in public projects. At **[1]**, the supported systems are specified. I personally use `x86_64-linux` and `aarch64-linux`, but I also usually support `x86_64-darwin` and `aarch64-darwin` in public projects.
If you want to support any system, you can use [`nixpkgs.lib.system.flake-exposed`] at **[2]** instead of defining your own list. If you want to support any system, you can use [`nixpkgs.lib.system.flake-exposed`](https://github.com/NixOS/nixpkgs/blob/374e6bcc403e02a35e07b650463c01a52b13a7c8/lib/systems/default.nix#L58) at **[2]** instead of defining your own list.
Because the definition is right inside the flake, you can tweak what gets passed to the function. For example, the [flake for RedoxOS-development] I contributed[^1] this to passes the custom rust-toolchain. Because the definition is right inside the flake, you can tweak what gets passed to the function. For example, the [flake for RedoxOS-development](https://gitlab.redox-os.org/redox-os/redox/-/blob/cb34b9bd862f46729c0082c37a41782a3b1319c3/flake.nix#L38) I contributed[^1] this to passes the custom rust-toolchain.
An example for how to do it is already right there: at **[3]**, `pkgs` is provided. An example for how to do it is already right there: at **[3]**, `pkgs` is provided.
Another possible tweak: You may want to define separate supported systems for each output. Another possible tweak: You may want to define separate supported systems for each output.
@ -105,10 +105,3 @@ For me, the trade-offs are worth it, as they provide greater transparency and co
That being said, I fully acknowledge that `flake-utils` can still be a great choice for many people. It simplifies things and reduces the need to write boilerplate code, which can be a big plus depending on your needs and workflow. Ultimately, it's a matter of personal preference and the specific requirements of your project. That being said, I fully acknowledge that `flake-utils` can still be a great choice for many people. It simplifies things and reduces the need to write boilerplate code, which can be a big plus depending on your needs and workflow. Ultimately, it's a matter of personal preference and the specific requirements of your project.
[^1]: If you check the history, you will see I am not mentioned. I am still a bit salty about that, as it was my first contribution to a bigger OSS project. [^1]: If you check the history, you will see I am not mentioned. I am still a bit salty about that, as it was my first contribution to a bigger OSS project.
[Nix]: https://nixos.org/
[servicepoint]: https://git.berlin.ccc.de/servicepoint/servicepoint
[machine configuration]: https://git.berlin.ccc.de/vinzenz/nixos-configuration
[flake-utils]: https://github.com/numtide/flake-utils
[`nixpkgs.lib.system.flake-exposed`]: https://github.com/NixOS/nixpkgs/blob/374e6bcc403e02a35e07b650463c01a52b13a7c8/lib/systems/default.nix#L58
[flake for RedoxOS-development]: https://gitlab.redox-os.org/redox-os/redox/-/blob/cb34b9bd862f46729c0082c37a41782a3b1319c3/flake.nix#L38