mirror of
https://github.com/foo-dogsquared/nixos-config.git
synced 2025-01-31 04:58:01 +00:00
3a022a374a
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 |
||
---|---|---|
.. | ||
home-manager/foo-dogsquared | ||
README.adoc |
Table of Contents
This is where user-specific configurations comes in. Ideally, the configurations are home-manager config.
Here’s an example of a sample user config placed in users/hello.nix
.
{ config, options, pkgs, lib, ... }:
{
programs.home-manager.enable = true;
programs.direnv.enable = true;
home.file.".npmrc".source = ./config/npmrc;
}
This is to be imported to homeManagerConfiguration
in the flake outputs and when indicated from config.modules.users.users
(e.g., modules.users.users = [ "hello" ];
).
Modules
There are also user modules (in ../modules/home-manager/
) that are imported to use with home-manager, allowing you to extend it as you wish.
It works just like home-manager modules.
For easier identification, it should be stored with modules
as the top-level attribute (e.g., modules.alacritty
, modules.i18n
).
Here’s an example user module that simply ports my Alacritty config.
{ config, options, lib, pkgs, ... }:
let
cfg = config.modules.alacritty;
in
{
options.modules.alacritty.enable = lib.mkEnableOption "Ports my Alacritty configuration.";
config = lib.mkIf cfg.enable {
home.packages = with pkgs; [ alacritty ];
xdg.configFile."alacritty" = {
source = ../../config/alacritty
recursive = true;
};
};
}