With images that are only exported as ISO (or even without one) are
included as part of NixOS configurations.
The idea with this attribute seems to be closer for deploying and
installing them with `nixos-install` which most of them aren't. This
might be reverted at some point. It's not clear to me yet.
It accepts keys used as arguments for deployment settings with
deploy-rs. This should make deployment a little bit easier for me
instead of manually creating a deploy entry every time.
Now we can finally easily declare the nixpkgs channel for individual
images. This is nice once I've expanded the images for other purposes
such as physical hosts (for homelabbing).
Unfortunately, this is where I realized that stable channels are not
exactly "Debian-stable" and the best way to handle security is to have
an update cadence that is relatively quick.
Additionally, I have also made a declarative version of the project
cluster with a neat little file at `images.toml`. This is way better for
individually referring to hosts from the host directory compared to the
old way.
It is pretty outdated and the CI didn't able to build the packages for
some time now (that I'm lazy to fix). Not to mention, some of them are
being upstreamed to nixpkgs so the need to use this is low. Also, it
causes the build to have some errors.
The latest update failed and that reminded me I mostly use steam-run now
which is more reliable and becoming my go-to tool for running unpatched
binaries in NixOS.
There are some parts of the config when imported with image modules
where it will set them with often default overrides. It is best to let
them override with our host config especially with the more important
options such as anything networking-related.
We've also removed the overlay because of troubles with building certain
package that is required to be in a specific version. Overlays are very
powerful but very unwieldy for a stable environment at times.
I forgot I set the home-manager values only to
`homeManagerConfigurations` in the flake output. It should be added to
the hosts configuration with the `home-manager.sharedModules` attribute.
Even though this will most likely extend under `tasks` attribute. Not to
mention, it is useless outside of my own setup anyways. Better be
accommodating than not, I guess.
All of the inputs are safe to follow the original nixpkgs. This is the
case for Neovim overlay that the lockfile is automatically updated and
the Emacs overlay simply has no lockfile.
It turns out the functions that is being wrapped by `mkHost` and
`mkUser` both accept `lib` as one of the attribute on their respective
functions. It is better to use that instead of chucking it as part of
`extraSpecialArgs` or something similar.
It doesn't make sense to put them into separate file anymore since there
is always only one location that uses it. The flake utilities have been
changed also with the updated version of the functions from its inputs.
Now that I have time, I've learnt that Git submodules are not supported
well with flake-based setup. Instead, I'll use my dotfiles repo as one
of the inputs as a non-flake which is exactly what I want. NICE!
Now that `system` top-level attribute in `configuration.nix` is
documented and comes with additional options now, we'll have to move the
system configuration into a new namespace. This is just the easy way
out.
- Update the attribute names with the latest stable release.
- Explicitly support only 'x86_64-linux' for now.
- Format the file with nixfmt.
- Update the project-local Nix settings.
There are now other user configs that make use of different attributes
from the flake itself. It is better to make `extraSpecialArgs`
configurable at this point.
