What is the point of `programs.nvchad.hm-activation`?

[aguirre-matteo]

The title. Why do we need an additional option to chose whether we want to make Home-Manager place the files at ~/.config/nvim? AFAICS, if programs.nvchad.hm-activation = false; then we just add the nvim binary to the PATH and add the .desktop file, which IMO doesn't make any sense to have a desktop file saying NvChad if in reality the config is not being applied.

If users want to install nvim but don't want to use NvChad's config then they can use programs.neovim.

[MOIS3Y]

    hm-activation = mkOption {
      type = types.bool;
      default = true;
      description = ''
        If you do not want home-manager to manage nvchad configuration, 
        set the false option. In this case, HM will not copy the configuration
        saved in /nix/store to ~/.config/nvim.
        This way you can customize the configuration in the usual way
        by cloning it from the NvChad repository.
        By default, the ~/.config/nvim is managed by HM.
      '';
    };
  };

For this reason ⏫ .
Simply to be flexible. If the user wants to add their nvchad configuration in another way, they won't rely on the hm.dag.entryAfter [ "writeBoundary" ] trick.

Let me remind you that we copy the configuration from /nix/store/*nvchad* to ~/.config/nvim.
This is not correct from the Nix perspective.

Why do we do this? Because the nvchad configuration modifies files in runtime, specifically chadrc when switching themes. /nix/store is read-only, and during such actions nvim will throw exceptions to the console.
So this was the only logical way that came to mind.

This still doesn't answer why the module is needed.
Actually, the module also does some other useful things specific to nix users.
You've probably encountered the problem where nvim in nix can't find a particular LSP server. Well, our nvim wrapper is built as a binary with wrapProgram $out/bin/nvim --prefix PATH : '${makeBinPath finalAttrs.buildInputs}'
which allows explicitly setting paths to the executable files of all packages passed to extraPackages.
This guarantees that nvim won't lose the path to the LSP, and you won't need to explicitly install them in home.packages or systemPackages.

P.S.
Of course, you can manage without this, especially if you develop under nix – you can always create a shell
with the necessary environment including LSPs, linters, and formatters.

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  name = "dev-environment";

  buildInputs = with pkgs; [
    gnome-builder
    flatpak-builder
    desktop-file-utils
    appstream
    gtk4
    libadwaita
    vala
    meson
    ninja
    pkg-config
    gettext
   # see ⬇️ 
    vala-language-server
  ];

  shellHook = ''
    echo "Development environment loaded with GNOME Builder, Flatpak, and related tools."
  '';
}

and not keep them in the system all the time if you don't code in that language regularly.

However, if you constantly edit bash scripts, you can explicitly specify that you want to be sure they are definitely available to nvchad.

    extraPackages = with pkgs; lib.mkDefault [
      # LSP servers
      nodePackages.bash-language-server
      docker-compose-language-service
      nixd
      # formatters
      nixfmt-rfc-style
      shfmt
    ];

[aguirre-matteo]

I took a look at the wrapper. So basically hm-activation = false is used if the user just wants to use Neovim along a series of extra dependencies (i.e LSP servers) in extraPackages but want to manage their config themselves?

EDIT: The wrapper checks if ~/.config/nvim/init.lua exists and, if not, it will copy Nvchad's config to that directory. If the user set hm-activation = false I guess it probably doesn't expects that to happen, but that's my personal opinion.

[MOIS3Y]

The last time I checked, the check for ~/.config/nvim/init.lua was working correctly — the configuration wasn't replaced if the file was present. This check happens at runtime and is needed for nix run github:nix-community/nix4nvchad/#nvchad.

When the user runs it, the flake.app is triggered. It copies the starter to /nix/store/*nvchad*, and upon launch, it will place it in ~/.config/nvim.

[MOIS3Y]

Here's an additional simple scenario of where this could also be used.
You're not using the home-manager module at all.
A simple starter is enough for you.
You install the package as a system package in
environment.systemPackages = [ inputs.nix4nvchad.packages."${pkgs.system}".nvchad ];
Let's say this is your VPS and you connect via SSH
ssh user@my.vps nvim (nvim will launch, if init.lua doesn't exist - the starter will be copied)
ssh root@my.vps nvim (nvim will launch, if init.lua doesn't exist - the starter will be copied)