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/
Rainbow parentheses were traditionally buggy with the plugins I used but
nowadays there are newer plugins available that use more flexible
technologies like treesitter.
See: https://github.com/hiphish/rainbow-delimiters.nvim
Useful when wanting to have a little fun with screenshots. Seems to
affect performance of fullscreen applications since those receive some
sort of priority when there are no other visible layers on the screen.
This makes the code base more portable by *only* depending on Nix as a
dependency.
Note that the code base hasn't been migrated to nixfmt-rfc-style yet.
Having a default.nix doesn't *really* make sense now that we're dealing
with multiple nixosConfigurations, some of which might not even be in
the same flake.
Now it's possible to use the specializations in arbitrary configs. Note
that specializations do slow things down a bit so they may be disabled
by default in the future.
Fixes an issue where the base16-schemes overlay wasn't being applied
presumably due to the separate nixosModule usage.
This removes Qt theming support, so it may be better to simply overlay
base16-schemes inside the module instead.
From a pragmatic perspective this never made sense since it would be
unlikely that we'd ever want to import multiple hardware configurations
at the same time.
An alternative solution would be to let users generate their own
hardware-configuration.nix that they can use with this nix-config, or
simply have them create their own nix-config that imports this flake and
uses the outputs they want.
The code for this is extremely messy right now however it works and I'd
rather not accidentally break it while refactoring, so this commit
serves as documenting the working code.
Now that I have more experience with nix, I know how to write an
expression that automatically outputs all the overlays in the
repository, as well as automatically import them inside the nixos
configuration.
This makes it possible to programmatically use all the outputs in a
flake without having to manually specify each one individually, useful
for having one main nix-config that can be used with other flakes and
system configurations.
I originally wrote default.nix files to "import all files in a given
directory" however this turns out to not be necessary when flakifying a
configuration and defining all modules, overlays, and packages as
outputs.
Instead of making these "default.nix" files the source of truth for all
imports, it should be more useful to make the flake.nix the source of
truth and programmatically use attribute values as needed.
