search

dustinlyons / nixos-config

General purpose Nix configuration for macOS / NixOS with starter templates + step-by-step guides ✨
BSD 3-Clause "New" or "Revised" License
1.78k stars 113 forks source link

Questions about development workflow #94

Closed gjolund closed 5 months ago

gjolund commented 5 months ago

In your readme you describe an ideal development workflow:

https://github.com/dustinlyons/nixos-config?tab=readme-ov-file#development-workflow

This is a beginner question, but how can I inspect and verify the results of a build prior to applying it via switch?

I can see the results directory is cleaned up on completion, but I am having a hard time finding docs on how to analyze the actual diff being applied.

dustinlyons commented 5 months ago

I think I can answer this in two ways.

The first way, is that Nix avoids some of this traditional problem of needing to verify changes before applying them go away.

How does it do this?

With Nix, it's (almost) symlinks all the way down. What I mean by this, is it replaces all of your packages and other software it manages with simple symlinks. The symlinks point to your current generation of whatever software it is at that time. Generations change when you run nix run .#build-switch and Nix detects changes it needs to make live. Kinda like a git log.

So "applying" a build in Nix, is just installing a new package in the Nix Store and updating the symlink. You're never actually "mutating" your system outside of swapping the symlink to another installation in the Store.

The new package sits right next to the previous one, so if something doesn't work, you just rollback to the last generation (i.e move the symlink to point to the other one).

On macOS, this is

darwin-rebuild list-generations
darwin-rebuild switch --rollback --generation <generation>

if you want to move to a specific generation, otherwise to just rollback to the last one:

darwin-rebuild switch --rollback

However, I will say that some of the nix-darwin stuff is imperative. I think that's just by design, given how MacOS works in some cases. For example, this configuration manages homebrew and Mac app store apps, which are installed and managed imperatively.

Now, the second way. Say you still want to see a diff. Generally, I just git for this and trust the Nix daemon. I can see the diff in what I'm telling Nix to do, which is good enough. There are other methods, though, like this project: https://github.com/Gabriella439/nix-diff

Hope this is helpful.

I'm also moving to use less packages in my main configuration, and more packages as part of projects I work on using devenv, direnv, and nix-direnv. You may check those out.

This keeps any "damage" to a smaller blast radius.

gjolund commented 5 months ago

@dustinlyons great answer, this helps with my mental model a lot.

what are some additional resources for learning about nix internals that you would recommend to someone just getting started who has a lot of experience managing linux but coming from tools like ansible?