I wrote a simple flake.nix that shows how to use this nix-config in your
own flake. This example in particular has been updated to show a working
demonstration with hyprland, although it's possible to use only parts of
this nix-config in e.g. headless environments as well.
Simplifies things a bit since my target audience includes those
interested in the Japanese language. Opinionated defaults like this
makes it easier for end-users to be immediately productive without
having to spend time configuring things.
Unfortunately command-not-found only works for channels and doesn't have
first-class support for flakes yet, and nix-index takes forever to build
the database on slower machines, so I'd rather just disable this by
default.
Seems like an alright categorization for now since dual-function-keys
can be used without a desktop environment, although realistically the
tty is impractical for things like CJK.
This makes it easier to ensure that the system has our network settings
such as random mac addresses. This makes sense since networking in
general is related to the system.
This isn't *perfect*, but it does make it possible to share files
between the guest and the host without having to imperatively create a
directory that may or may not exist on other systems.
It may be useful to add hashedPasswordFile in the future, although from
my testing it was possible to rebuild a VM that used a cached derivation
with the old password.
Ideally your main form of authentication is through LUKS encryption or
SSH keys anyway, and this password should solely be used for sudo
purposes.
Will extend upon this later, but this basically makes it possible to
guarantee that the flake can be used inside another flake and be
customized as expected.
Note that hardware-configuration.nix is optional if you're just using
the configuration for virtual machines and containers, which is why it's
optional here. A default file isn't provided to help users understand
that they have to bring their own.
Not really necessary anymore since I no longer test home-specific stuff
inside the virtual machine.
It would be nice if there was a way to create a temporary directory on
the fly (such as one in /tmp) that could be mounted and used for sharing
files between the virtual machine and the host.
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 increases boot times quite a bit so I'd rather use tmpfs as /tmp
where possible. Note that this defaults to cleaning /tmp anyway since
I'd rather clean /tmp than not do so at all.
For future reference, the message that gets shown is the following:
"A start job is running for Create Volatile Files and Directories"
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.
Necessary since system now depends on home-manager and desktop depends
on stylix, which also depends on home-manager.
Note that since conditional imports can't be used and we include the
system module inside of our containers which don't have access to self,
importing the required modules inside the module itself cannot be used.
