flake-utils VS nix

The ‘flake-utils’ readme is a pretty good jumping off point: https://github.com/numtide/flake-utils

I have this or that nitpick with FL and FLP but overall it’s very solid stuff. FLP is a little more “magical”, and that’s not always the best starting out, but you really can’t go wrong with either.

We added two inputs, the first is nixpkgs which lets us specify which version of nixpkgs we should use. There are many thousands of packages in the nixpkg repository, and they are updated often so here will use the unstable branch. We also added flake-utils which helps us generalize the flake to support multiple systems, not just Linux.

The inputs is how you can import external sources of other flakes into the flake project you have. In other words, any project you may need or tools required to get started, this is where you will define their source. Example below is using the standard nixpkgs and a tool called flake-utils, which provides a set of functions to make flake nix packages simpler to set up without external dependencies.

I'm not sure what nix-shell --pure does, but is it equivalent to using a flakes.nix in your projects? Ie i use https://github.com/numtide/flake-utils and direnv to replicate the old shell.nix with a Flakes setup. Per project i have a flakes.nix and a flakes.lock, so it feels just like my old shell.nix setup, but using flakes instead.

A Nix Flake is just an object - check out those surrounding curly braces. This object has two keys, inputs and outputs. The inputs are where we define the flake's dependencies and where to find all the tools we use. This one has two, nixpkgs and flake-utils. Each of these just points to a GitHub URL, and if you follow those links, you'll see each repo provides its own flake.nix. The outputs of each remote flake get piped into the inputs of my flake, so we can use what they provide.

You can easily transition your shell.nix (and default.nix) to a flake-based one by using flake-utils and flake-compat. The former is actually unnecessary, but I would recommend it for typical project environments. Unless you have an impure dependency, this transition would be easy.

Flakes can provide different types of things: - some flakes provide applications that you can nix run, - some flakes provide functions that you can import (e.g. https://github.com/numtide/flake-utils), - some flakes provide overlays to use with nixpkgs (e.g. that emacs-overlay you posted).

> https://github.com/NixOS/nix/pull/9911#issuecomment-19252073...

As we covered in my last post, NixOS is a amazing Linux distribution for creating stable and declared environments. Now while this is amazing for a desktop setup, it is also perfect for a home-server or home-lab.

(Nix itself is slowly chugging along with Windows via MinGW - https://discourse.nixos.org/t/nix-on-windows/1113/108 and https://github.com/NixOS/nix/issues/1320 , for example.)

Nix is a cross-platform package manager. It uses the nix programming language. Nix and NixOs are often used in the same context, but while the first is a package manager, the latter is a linux distribution based on nix.

Today I want to talk to you about Nixos. What is it? Nixos is a declarative and reproducible OS, partly taking the words used on their own page. What does that mean?

Software developers often want to customize:

1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).

2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.

3. or even their operating systems: for development, for CI, for deployment, or for personal use.

Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):

- reproducible: what works on your dev machine also works in CI in prod,

- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction,

- reliable: all changes are atomic with easy roll back.

Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.

- it reduces bloat, because you can generate an environment or OS image with only the software needed to run a specific program or service

My guess is that a big efficiency gain would come from the second point, because you don't waste CPU on code that you don't use.

Does this make sense? Has anyone explored this?

[0]: https://nixos.org

1) Setting up the development environment - I currently use devcontainers for most things, but may also dig into nix -> isolated, portable, repeatable development environment 2) Exploring Echo - understand routing, requests, response, etc. 3) Incorporate Templ - integration with Echo, template composition, etc. 4) Integrating TailwindCSS - config for use with Echo/Templ, development cycle, deployment, etc. 5) Add in HTMX - endpoints, template structure, concepts, etc. 6) hyperscript for interactivity - client side interactivity