This is a part of making it easier to instantly have access to yazi
without having to worry about using home-manager. Note that this works
for my use case since I don't use Nix on non-NixOS devices and don't
intend to do so anytime soon.
This continues the process of simplifying the available modules for
end-users. The final result would be having a clear set of modules like
"desktop" and "shell" that can be enabled if users want a complete
Hyprland environment or a complete shell environment.
Enabling the stylix module "only" would be a low-tech solution and at
that point it'd likely be better for end-users to take complete control
of their stylix config with their own module.
Thunar is an opinionated file manager that we're using as the GUI
application of choice because it handles directories with large files
*significantly* better than Nautilus. It also supports image previews
for files that have been trashed, as well as a slew of other convenience
features such as a built-in auto-renaming tool.
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).
