From cec95952d278f1a10d03ec5860b5c8ccb99bf271 Mon Sep 17 00:00:00 2001 From: Vinzenz Schroeter Date: Mon, 7 Apr 2025 18:25:01 +0200 Subject: [PATCH] remove old theme, first post --- content/posts/hello-world.md | 7 -- content/posts/why-i-do-not-use-flake-utils.md | 113 ++++++++++++++++++ flake.nix | 17 --- 3 files changed, 113 insertions(+), 24 deletions(-) delete mode 100644 content/posts/hello-world.md create mode 100644 content/posts/why-i-do-not-use-flake-utils.md diff --git a/content/posts/hello-world.md b/content/posts/hello-world.md deleted file mode 100644 index a995a00..0000000 --- a/content/posts/hello-world.md +++ /dev/null @@ -1,7 +0,0 @@ -+++ -date = '2025-04-06T12:24:08+02:00' -draft = true -title = 'Hello World' -+++ - -# this is a test diff --git a/content/posts/why-i-do-not-use-flake-utils.md b/content/posts/why-i-do-not-use-flake-utils.md new file mode 100644 index 0000000..afefc04 --- /dev/null +++ b/content/posts/why-i-do-not-use-flake-utils.md @@ -0,0 +1,113 @@ ++++ +date = '2025-04-06T14:49:03+02:00' +draft = false +title = 'Why I do not use flake-utils' +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. + +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. + +### Without anything + +```nix +{ + description = "Flake utils demo - without flakes"; + + outputs = { self, nixpkgs, flake-utils }: + { + packages."x86_64-linux" = rec { + hello = pkgs.hello; + default = hello; + } + packages."aarch64-linux" = rec { + hello = pkgs.hello; + default = hello; + } + + # more systems ... + } +} +``` + +### With flake-utils + +```nix +{ + description = "Flake utils demo"; + + inputs.flake-utils.url = "github:numtide/flake-utils"; + + outputs = { self, nixpkgs, flake-utils }: + flake-utils.lib.eachDefaultSystem (system: + let pkgs = nixpkgs.legacyPackages.${system}; in + { + packages = rec { + hello = pkgs.hello; + default = hello; + }; + } + ); +} +``` + +### With function in flake + +To make a long story short, here is what I usually do instead: + +```nix +{ + description = "forAllSystems demo"; + + outputs = { self, nixpkgs }: + let + supported-systems = [ # [1] + "x86_64-linux" + "aarch64-linux" + ]; + forAllSystems = + f: + nixpkgs.lib.genAttrs supported-systems /* [2] */ ( + system: + f rec { + pkgs = nixpkgs.legacyPackages.${system}; # [3] + inherit system; + } + ); + in + { + packages = forAllSystems ({ pkgs, ... }: rec { + hello = pkgs.hello; + default = default; + }); + } +} +``` + +That’s definitely more code! - Yes, but it also includes more information in the flake, while getting rid of an external dependency. +While more code can be intimidating for beginners, it actually helps remove a barrier to understanding how the flake works in this case. +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. +If you want to support any system, you can use [`nixpkgs.lib.system.flake-exposed`] 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. +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. +This is useful, for example, if the target environment you're developing for cannot support a development shell. + +For me, the trade-offs are worth it, as they provide greater transparency and control over the flake configuration. + +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. +[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 diff --git a/flake.nix b/flake.nix index fb25e81..905e061 100644 --- a/flake.nix +++ b/flake.nix @@ -26,23 +26,6 @@ packages = forAllSystems ( { pkgs, ... }: rec { - hugo-theme-m10c = pkgs.stdenv.mkDerivation { - pname = "hugo-theme-m10c"; - homepage = "https://themes.gohugo.io/themes/hugo-theme-m10c/"; - version = ""; - - src = pkgs.fetchFromGitHub { - owner = "vaga"; - repo = "hugo-theme-m10c"; - rev = "862c6e941be9bc46ce8adc6a2fa9e984ba647d6f"; - hash = "sha256-wcJSGjL/u43hPLblPmUhusqiMmadVBWJhihRinRXqzg="; - }; - - installPhase = '' - mkdir -p $out - cp -r * $out - ''; - }; hugo-theme-poison = pkgs.stdenv.mkDerivation { pname = "hugo-theme-poison"; homepage = "https://poison.lukeorth.com/";