Nix-Gui: Use NixOS Without Coding

Announcements
1

Announcing Nix-Gui (v0.1 beta)

A project with the ambitious goal of making NixOS the most user friendly GNU/Linux distro.

image
image1920×2088 335 KB

(Please see the linked Github readme for a broader overview, the Motive, Functionality, Features, and Shortcomings sections below are quoted from there)

Motive

The declarative nature of NixOS provides it the capability of being the most user friendly linux distro. No more editing dotfiles, /etc files, manually writing timers, services, running commands to manage and create users and groups, etc. NixOS integrates all of that into a declarative system, and this project integrates NixOS’ declarative system into a GUI.

Functionality

Nix-Gui is a tool which loads data including option paths, option types, default values, configured values, descriptions, etc. The option hierarchy is made explorable and the value of individual options are editable. Changes are committed by writing to modules within the configuration path.

This data is retrieved from <nixos/nixpkgs> and from the configuration path via NIX_PATH nixos-configuration.

Features:

  • View and edit the state of options using type-specific widgets (e.g. textbox for strings)
    • View and edit the actual nix expression defining an option
    • View metadata of an option including type and definition
  • Save changes to a relevant module in the configuration path
    • “Diff” to show option changes not yet committed to disk
  • Explore the hierarchy of options
    • Utilize color indicators to show which options have been set
  • Search options based on options path, type, and description
  • Undo changes to options

Shortcomings

Currently there are a few major limitations to Nix-Gui, including

  • Documentation is entirely incomplete.
  • Nix-Gui requires that configuration.nix be a function module. It cannot handle set modules. (attempt to call something which is not a function but a set ¡ Issue #54 ¡ nix-gui/nix-gui ¡ GitHub)
  • The interface for ListOf and AttrsOf is incomplete.
  • Nix-Gui has yet to be thoroughly vetted, therefore the configuration path is copied to ~/.config/nixgui/configurations/, in which all changes made by Nix-Gui are saved.
  • Not all data structures used in this application are optimal, resulting in some configuration paths taking longer than I’d like to load (profile navlist color selection and optimize ¡ Issue #128 ¡ nix-gui/nix-gui ¡ GitHub).
  • Some option types aren’t handled yet (e.g. float, package, lambda, and specific types like ncdns.conf configuration type, systemd option). These options can only be edited as a nix expression, as they do not have a matching widget.
  • The UX hasn’t yet received any comments from the community .

Running

Prerequisites:

  • Ensure nixos is installed
  • Ensure nix.extraOptions = ''experimental-features = nix-command flakes''; is set in configuration.nix (and you’ve rebuilt) to enable Nix Flakes.

Run

  • nix run github:nix-gui/nix-gui nix-gui

Print help string

  • nix run github:nix-gui/nix-gui nix-gui -- --help

Roadmap

Short term goals (v0.2)

  • Fix the problems in the “Shortcomings” section.
  • Solicit UX feedback

Medium term goals (v1.0)

Long Term Goals (v2.0+)

Please Help with Testing UX Feedback

Run Nix-Gui and create issues for bugs you encounter here.

Please fill out the UX Survey

41 Likes
2

I had an idea to start a similar project, but now it seems as though I don’t have to! Looking forward to learning more!

3

One thing I had considered was looking to see if the kconfig tooling could in any way be useful (like, generate kconfig syntax from nix derrivations), because there’s a lot of overlap here between nixos options and kernel config options.

The issue I think you run into is that nix, being a programming language, has a tree structure. And I feel like trees and guis are kindof a mixed bag. It’s easy to implement, it’s hard to use. And my experience with auto-generating UIs from property lists is that, for any given set of properties, there’s probably a hand-written layout that would be easier to use.

On the other hand, if you can integrate package / option query / filters with immediate editing into a tight loop, it would make configuring nixos easier.

4

Happy to see the birth of such a project!

Good job, really looking forward to it.

5

Hi

Yes, if that would be possible i could try Nixos. Because a lot off features in NixOs that i really want and miss in other dristro’s, but to difficult to configure.

But still it would be easier that their would be a kind of ‘standard/default normal’ user NixOs installer that works nice out of the box.
And while using that as a ‘normal’ daily Linux system we can learn more and more the Nix way.

So, this is a nice step in the good direction, i think.

Regards

6

Apparently something’s in the air! This is something that I’ve been thinking about on and off for years, and I just a couple of weeks ago decided “okay, I’m going to actually do it!” I was asking around, and someone pointed me here!

@andrewlapp I would love to get involved in brainstorming / designing / implementing. If you have time to chat about this, send me a DM. Most days after ~16:00UTC works for me.

If not, I’ll probably start working on the installer side of things, since that’s a mostly separable piece of the puzzle.

7

I just want to throw in the idea seedling of the logseq interface, which mixes markdown with enhaced widgets of the category that we are talking about here.

A good system config would probably read like a book with some notes leading to and documenting the concrete config choice.

In JS there is also a similar precedent with MDX inter-mixing markdown and code elegantly, so that it can be consumed by both humans and machines, equally well.

Lastly, I’d find it really exciting if we could have a gui tool tunning on nixgui.org where people can craft their initial config and then safe their flavour directly to a git repo (very similar to logseq web).

1 Like
8

Newb question:

Looking at https://github.com/nix-gui/nix-gui/blob/9490067b25d8fc52795329b9ba072ced570b528b/docs/usage.org#running, I am seeing nix-flakes. How much does this depend on nix-flakes, and how much of nix-flakes do I need to understand before I can install/use this GUI?

I’m not familiar with nix-flakes, so I cannot easily see what the dependency is for. Or maybe I misunderstand what is needed to install and use the tool?

1 Like
9

Nix-Gui doesn’t support editing flakes yet, however it is built using a flake (https://github.com/nix-gui/nix-gui/blob/9490067b25d8fc52795329b9ba072ced570b528b/flake.nix).

All you need to know about flakes is how to enable it per the instructions in your link so the command nix run github:nix-gui/nix-gui works. If you don’t have flakes enabled it will not work.

1 Like
10

I like parts of the idea a lot. My main concerns are

  • feature creep, especially in terms of the ability to publish notes
  • noobs not understanding that their notes are public

Perhaps there could be a public repo containing an org file for every nix option that could be populated by contributors and displayed by Nix-Gui, and Nix-Gui could be built with this repo as a dependency. This would remove the need for a note publisher integrated into Nix-Gui and also make sure noobs can’t accidentally publish private notes.

Additionally, scripts could potentially populate files with data from other documentation sources.

This wouldn’t exactly logseq (as I understand it) since it’s not as streamlined.

11

Oh, yeah, by all means no note-publisher.

More like: render all markdown as markdown-styled nix source code comments (directly within configuration.nix)

That’s it.

By the way, let the DevOS community know what it takes to make divnix/devos interoperable

1 Like