At some point this started causing the /run/user/1000 directory to be
deleted when changing container configurations, which was definitely not
ideal.
An alternative approach will have to be taken if we want the wine
container to auto-start on boot.
This is the start of my fun attempt at using NixOS containers for web
services as a Docker replacement.
After spending some time on other servers I realized that I don't
actually *need* my dotfiles on those servers, so it becomes
significantly faster to build these containers without worrying about
home-manager and command-line programs I use on the host.
Main advantages include web service configuration with Nix instead of
Docker. Disadvantages include increased complexity for anything that
isn't already maintained by others in nixpkgs.
It turns out that I shouldn't actually need graphical container support
for most containers, which might also improve build times with multiple
containers.
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.
