Notes on LinuxBeginnings/NixOS-Hyprland — evaluating whether to adopt it, and how the installer actually works under the hood.

Install scripts

Two entry points at repo root, sharing helpers from scripts/lib/install-common.sh:

auto-install.sh — the curl-piped bootstrap for a machine that doesn’t have the repo yet. If ~/NixOS-Hyprland already exists it moves it to ~/NixOS-Hyprland-backups/<timestamp> and does a fresh git clone --depth 1, then runs the same flow as install.sh.
install.sh — run from inside an already-cloned repo. Checks NixOS/git/pciutils/Go version, prompts for hostname/keyboard/timezone, detects GPU via lspci/hostnamectl and toggles the right driver flags, generates hardware.nix via nixos-generate-config, patches flake.nix, then sudo nixos-rebuild switch --flake ~/NixOS-Hyprland/#<hostName>.
scripts/lib/install-common.sh — shared functions: nhl_detect_gpu_and_toggle, nhl_prompt_timezone_console, nhl_check_go_version (needed for building waybar-weather).

Post-rebuild, both scripts also (imperatively, outside Nix):

back up/copy assets/.zshrc to ~/.zshrc
clone GTK-themes-icons and run its auto-extract.sh into ~/.icons/~/.themes
clone Hyprland-Dots and run its copy.sh — this is where the actual hyprland.conf/waybar/hypridle/hyprlock/rofi config comes from, not from the Nix flake
mask the user waybar.service to avoid a duplicate bar

Will the flake build without running the scripts?

Yes, evaluation-wise — but two values are hardcoded in flake.nix rather than templated, and the scripts just sed them:

host = "jak-hl";
username = "dwilliams";

These are the maintainer’s own hostname/user, not placeholders. Also hosts/default/hardware.nix is someone’s real generated hardware config (hardcoded disk UUIDs, an NFS mount) — install.sh regenerates this via sudo nixos-generate-config --show-hardware-config for your actual disks before rebuilding.

Skipping the scripts and hand-editing instead works fine:

edit host/username in flake.nix
sudo nixos-generate-config --show-hardware-config > hosts/<host>/hardware.nix yourself (same command the script runs)
hand-flip the drivers.amdgpu/intel/nvidia/nvidia-prime.enable / vm.guest-services.enable flags in hosts/<host>/config.nix
set keyboardLayout in variables.nix, time.timeZone/console.keyMap in config.nix
sudo nixos-rebuild switch --flake .#<host> directly

But modules/home/default.nix (the home-manager config actually wired into the flake) only manages CLI tools — tmux, nixvim, bat, btop, eza, fzf, git, yazi. No Hyprland config, no waybar, no rofi, no wallpaper anywhere in the Nix modules. So building the flake alone gets Hyprland installed but unconfigured — you still need the separate Hyprland-Dots clone + copy.sh (and optionally GTK-themes-icons) for the actual desktop experience, even when skipping the NixOS-layer installer.

Keeping up to date after hand-editing

The repo’s own update model is destructive, not incremental: re-running auto-install.sh backs up and re-clones (shallow) from scratch. That’s incompatible with hand-edited host files, so:

Clone with full history (no --depth 1) so merge/rebase actually works.
Fork on GitHub if I want my edits versioned; add upstream remote pointing at LinuxBeginnings/NixOS-Hyprland.
Put all machine-specific edits in my own hosts/<unique-name>/ dir, never hosts/default or an existing maintainer host (jak-hl, nixos, nixos-test) — that dir never exists upstream, so it never conflicts on merge.
Expect occasional manual conflict resolution on flake.nix itself (the host/username lines) since they’re inline in the shared outputs block rather than per-host — usually trivial, only conflicts if upstream touches the same lines.
Routine: git fetch upstream && git merge upstream/main, check CHANGELOG.md for breaking changes, resolve the flake.nix conflict if any, sudo nixos-rebuild switch --flake .#<host>.
Don’t run my own nix flake update — pull the maintainer’s flake.lock via merge instead, since that reflects revisions they’ve actually tested (README warns their flake tracks nixos-unstable, which can break things).