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.
The addition of the neovim plugins made the initial time to open longer
than 5 seconds and thus failed the tests.
Note that using an alternative method like machine.wait_for_text() is
probably better in the long run to avoid flaky tests.
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.
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.
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/
Note that these tests were originally made to prevent dead code from
being in the repository, although a proper coverage solution would
likely be more useful long-term.
2 months ago, I figured out how to make Crystal work on NixOS and made
an upstream PR to fix Crystal being unable to find -lpcre. Unfortunately,
that change hasn't been merged yet and I even encountered a core dumped
error when trying to build Crystal myself recently.
Although people may be busy, I am concerned about the popularity of
Crystal relative to other languages. It could be the case that the build
was broken for so long precisely because no one used Crystal, and that
the language isn't popular enough to generate comments on the patch either.
In any case, JavaScript/TypeScript is here to stay, and it certainly has
better tooling and community support than Crystal at the moment. Deno
has been going strong for a few years now, and now that I know Rust, I
can also contribute to it if I want to.
