Gabriel Arazas
e4e133dc9f
Some checks failed
Build devcontainers / build-devcontainers (push) Has been cancelled
Cache outputs / build-custom-packages (push) Has been cancelled
Check flake outputs / check-outputs (push) Has been cancelled
Publish every Git push to master to FlakeHub / flakehub-publish (push) Has been cancelled
Build personalized bootstrap ISO / build-iso (x86_64-linux) (push) Has been cancelled
Build project site / build (push) Has been cancelled
Build project site / deploy (push) Has been cancelled
Update Firefox addons / update-firefox-addons (push) Has been cancelled
|
||
---|---|---|
.. | ||
disko | ||
flake-parts | ||
home-manager | ||
nixos | ||
nixvim | ||
wrapper-manager | ||
README.adoc |
This is the folder containing various configurations for various environments, typically the ones configured using the Nix module system such as NixOS, home-manager, and nixvim. Each of these configurations are assumed to use custom modules defined at ../modules/ (where it has similar folder structure).
Furthermore, these configurations do have a certain "codename" in the commits for easier inspection of the history. Here is the following list of them used in the repo history:
-
diskoConfigs
for Disko configurations. -
hosts
for NixOS systems (e.g.,hosts/ni
). -
users
for home-manager configurations (e.g.,users/foo-dogsquared
). -
nixvimConfigs
for NixVim configurations (e.g.,nixvimConfigs/fiesta
). -
wrapperPackages
for wrapper-manager packages (e.g.,wrappers/archive-setup
). -
flake
for flake-parts (seeing it only has one of them, it is constantly referred to asflake
).
These "codenames" are also used for their environment-specific module structuring (e.g., hosts.ni.services.backup.enable
for NixOS, nixvimConfigs.fiesta.setups.tree-sitter
for NixVim, users.foo-dogsquared.setups.desktop.enable
for home-manager) with the exception of flake-parts where it is basically a free-for-all.
Lastly, these modules are referred collectively in the commits as modules
.
Conventions
There’s a few things you need to remember for these configurations.
-
Module arguments that are only suitable to be included in the first build step of the configuration are all under the
firstSetupArgs
namespace. -
Module arguments that are only found inside of the configuration itself should be under the
configurationArgs
namespace.