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.
The overlay is most likely for show and not going to be used only for my
experiments due to the service not working well. I may just use the
binary installation instead if this didn't work.
- Add `modules.desktop.cleanup` for the usual cleanup activties in
NixOS.
- Update to proper descriptions for module options added with
`lib.mkEnableOption`.
- Additional packages for various modules.
- Deleted `modules/home-manager/alacritty`. It is pretty useless though.
:(
I think this is better for separating modules explicitly. This is also
considered as there are similar objects between modules (e.g., NixOS
and home-manager modules and users).
Revert users module to old position
- Remove package outputs for MacOS since I don't have any.
- Import our custom packages as an overlay for our NixOS configs.
- Recursively import our modules which is more correct.
I revisited NixOS this week and I've rewritten my NixOS config from
scratch. I must say I really like Nix flakes. For whatever reason it
just clicked and I understood more programming with Nix despite my
previous experience which is not good. Could be just the fact I had a
break for a long time from completely using Nix (I still used it on
non-NixOS distros).
Eh... I still took some things from the original inspiration of this
configuration so there's that.