Reviewing and applying
Everything you stage collects on the Changes page. The sidebar entry shows the number of pending changes, for example Changes (3).
The Changes page
At the top you see the system the changes are for (Target: flake and host) and the generated entry file (File:).
Pending changes lists each staged change: an option with its new value, a package to add or remove, or a setting to remove from the generated file. Under each option you see its priority, input mode and host scope when they are not the defaults, and the result of the type check. Click an option to open its details; click the undo button at the end of a row to unstage it.
Managed by DrakeFlake lists what the generated file already sets. To hand a setting back to the rest of your configuration, click the remove button next to it; this stages its removal.
Messages above the list warn you when something would keep your changes from working, for example:
- “Your configuration does not import … yet”: add the import line (see the setup assistant).
- “… is not tracked by git, so the flake cannot see it”: click Track in git.
- The generated file is outside the flake, or the flake is not a local folder.
- Some staged values do not match their option type. Fix or unstage them; until then you cannot apply.
Previewing the generated files
Click Preview file to see the files exactly as they would be written, with
syntax highlighting. With a split layout, each file starts with a ### path
line. Copy copies the whole preview.
Applying
The toolbar has the two common actions; the menu (⋮) has the others.
| Action | What it does |
|---|---|
| Apply | Save the files, build the system and switch to it now. It also becomes the default at boot. |
| Review and apply… | Save the files, then let nh build, show what changes (packages, versions, size) and ask before switching. |
| Review and apply on next boot… | Like the above, but the new system becomes the default from the next boot on. |
| Save only | Write the files without rebuilding. |
| Save and test build | Write the files and build the system without activating it. |
| Apply until reboot (test) | Build and activate the new system now, without making it the default at boot. |
| Apply on next boot | Build the system and make it the default from the next boot on. |
| Discard all | Drop every staged change. |
When you apply, the app:
- renders the generated files and checks their Nix syntax,
- refuses to rebuild if your configuration does not import the generated file (Save only still works),
- backs up the current entry file (see History),
- writes the files; if it may not write to the flake folder (for example a
root-owned
/etc/nixos), it asks for your password and writes them with the helper, - marks new files for git (
git add --intent-to-add), - builds the system as your user, with
nh os buildor, without nh,nixos-rebuild build, - activates the built system as root, asking for your password.
The window switches to the Console, where you follow the output. The status bar shows “Applying changes…” while it runs, and the console ends with Done. or with a failure message.
Review and apply with nh
Review and apply… runs nh os switch (or boot) with --ask inside the
app. nh builds the system, prints the package differences and then asks whether
to continue. The question appears as a bar above the console output with Yes
and No buttons. Review needs nh; the app tells you to use Apply when nh
is not installed.
The Console
The Console shows the output of everything the app runs for you: builds, updates, comparisons and cleanups. Each command is shown before its output.
- Cancel stops the running command.
- Copy copies the whole output; Clear empties the console.
- Restore previous file appears after a failed apply: it puts the generated file back as it was before.
Password prompts
Most password prompts are your desktop’s polkit dialog. When there is no setuid
pkexec, the app uses run0 or sudo instead and says so in the console. If
such a program asks for your password in the console, a password bar appears
above the output: type the password and click Send. The password is passed
to the program only; it is never shown or written to the log, and the prompt
line is hidden from the output.
See Privacy and security for what runs as root.
Git
Flakes only see files that git tracks. When the app creates a new generated
file inside a git repository, it marks it with git add --intent-to-add, so
the flake sees it without you committing anything. If that fails, the Changes
page shows a warning with a Track in git button.
Commit the generated files together with the rest of your flake whenever you like; the app does not commit or push anything.
History and restoring
Every save keeps the settings it replaced. The History page lists these earlier states, newest first: when they were replaced, how many settings and packages they hold, and what restoring them would change.
To go back, click Restore. The app writes those settings back (and keeps the current ones in the history). Rebuild afterwards to use them, for example with Apply on the Changes page.
The backups are stored outside the flake, in
~/.local/state/drakeflake/backups/ (or under $XDG_STATE_HOME when it
is set), so they are never imported or committed.