This fixes an issue where previously homeManagerModules would be an
unknown flake output. Note that this change is a part of Nix 2.22.3
but not Nix 2.23.3.
This is necessary since the boot process is handled by mobile-nixos.
Note that the implementation here should allow us to move aarch64
differences out of the flake.nix and simplify nixosConfigurations
again long-term.
This was my attempt at using GNOME Mobile. It works inside the x86_64
virtual machine but fails when reaching "Started Display Manager" on the
actual device.
This makes sense to avoid having to cd into the phone directory before
being able to do anything.
Note that this time we aren't trying to combine the phone config with
the existing nix modules to keep things simple.
This was causing a lot of issues unfortunately presumably due to things
not working with the aarch64 PinePhone system. Random errors like
"expected string 'D'" were common and I'd rather use a separate flake to
make things easier to debug and keep evaluation times to a minimum.
Note that using a separate fork is necessary since overlaying flakes
seems to be non-trivial here.
Also note that previously the nixpkgs hyprland was being started from
greetd. This fixes that.
Note that we will continue to use nixpkgs-fmt for the time being here
since nixfmt-rfc-style breaks string syntax highlighting and comments
like `/* this */` get turned into `# this`.
The conversion from lisp-like formatting to something else in flake.nix
is a bit unfortunate, but I'd rather have a singular style for the
entire code base to make things easier.
This change makes it possible to use this nix-config in all the
different ways imaginable (containers, bare metal, tests, and as a
separate flake input) *without* running into infinite recursion
issues with self.
It does this by using a trick similar to JavaScript in which
`var self = this;`, thus enabling the usage of "this" (or self, in
Nix's case) where it wouldn't otherwise be possible.
Note that this *only* works if the input for this repository is named
nix-config. This makes it impractical to combine with multiple
configurations that employ the same strategy.
This change makes it possible to import the modules that are required
from the flake inputs in the output modules themselves, thus preventing
users from having to manually import those modules.
This simplifies things overall and was made possible by the specialArgs
option that allowed these flake inputs to be passed into our container.
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.
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/
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.
