Realistically I want access to htop on any machine running my shell
configuration. Making this NixOS-specific removes some of the dependence
on home-manager as well.
Long-term this should make it easy to include all the GUI programs with
the desktop module and all the CLI programs with the shell module, as
well as the ability to easily disable sets of unneeded packages.
This is the start of making it possible to include desktop-related
configuration options instead of only hyprland-related ones.
This simplifies things a bit since opinionated configurations can be
hidden behind an option and end users won't have to worry about all
the different possible modules they could import.
This change is a part of making the desktop-specific stuff its own
module. Note that importing the entire hyprland module into the wine
container doesn't seem to change anything, so simplifying and including
everything in this module should be fine.
I originally separated these modules to avoid "opinionated" options like
neovim as the default editor. Now I realize however that it's easier to
load all opinionated settings by default since users can change them
either through the original options or with module-specific options.
By making this module more generic, it becomes possible to include CLI
programs and other applications as part of the "shell", then provide
options for users to enable or disable things as needed.
Realistically if hyprland is being used then the user *probably* wants
audio as well, so merging them makes sense here.
This commit is a part of ultimately having a single module for "desktop"
usage.
These options are pretty important so it'd be cool to be able to change
them. Current strategy is to assume that configuration through the
module is preferred over overriding the NixOS option directly.
This seems like it could fit with the hardware module as well, however
time will tell if we're able to keep this in system when importing it
into containers and virtual machines.
Note that boot.loader.efi.canTouchEfiVariables gets set to true during
the nixos-install process, so it should be okay to keep here.
Usually one would want to define all of these options at the same time,
so it doesn't make sense to require importing several different modules.
For values that aren't needed, users can either override the configuration
in their own module or use an option that has been written upstream for the
module.
Docker feels a bit too old school after being spoiled by the Nix
language and all the features that NixOS provides. Dockerfiles are not
as cool to write as Nix files and docker-compose.yml lacks many of the
reproducible benefits one gets from sticking with Nix.
Now that I have more experience with Nix, it should be possible for me
to build and run the services I want to run with Nix instead of Docker.
This should additionally reduce my personal machine's startup time,
which was already quite low with Hyprland.
As a final closing, expertise in Nix seems more useful than Docker for
my personal goals. I'd rather be able to control entire Linux systems
and their full environments with containers, virtual machines, and other
goodies than be restricted to the simplistic model that is Docker.
Specializations basically double the build time for each one added, so
requiring users to explicitly enable it means quicker build times for
those that prefer Hyprland (which is easier to configure declaratively).
Now that I've figured out how to dynamically import modules and use
those modules as outputs, the next step is to ensure that these modules
work as intended when being used by end users.
NixOS offers a built-in testing solution that enables us to conveniently
spin up virtual machines with a given configuration, then verify their
correctness through python scripting.
The lib.nix file in particular is based on Jörg Thalheim's very useful
blog post that explains how to use the built-in testing functionality
with Nix flakes, which isn't covered in official documentation.
See: https://blog.thalheim.io/2023/01/08/how-to-use-nixos-testing-framework-with-flakes/
