dots-hyprland/sdata/dist-nix/README.md

Install scripts using Nix to achieve cross-distros

• This directory is currently WIP.
• See also Install scripts | illogical-impulse
• See also #1061

NOTE: The dist-nix is not for NixOS but every distro, using Nix and home-manager.

As we all know Nix and Home-manager has two major functionalities:

• Handling dependencies (i.e. package installation)
• Handling dotfiles

They are discussed in following sections.

Handling dependencies

Status

Partially works. See Discussion #2382.

plan

Note that this script must be idempotent.

TODO:

• Fix all TODOs inside dist-nix. (search online)
• Since Nix uses a large number of inodes, need to warn user if inode-limited filesystem (typically ext4) is used.
• Deal with error when running systemctl --user enable ydotool --now:

  Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
  

• Handle problem that pkill qs and pkill hyprland does not work (should be .quickshell-wra and .Hyprland-wrapp when installed via Nix).

Attentions

PAM

On non-NixOS distros, programs using PAM (typically screen locker) will not work if installed via Nix, so user has to use their own distro's package for the screen lock.

• One problem is that Debian(-based) distros use modified version of PAM which supports @include directive in /etc/pam.d config files but the PAM from Nix does not support it, see this comment.
• Another problem is the location of a suid helper binary that is necessary, see this comment.

As commented by @Cu3PO42 , both the problem could be solved by using the system-provided libpam instead.

See also caelestia-dots/shell#668.

NixGL

On non-NixOS distros, packages installed via home-manager have problem accessing GPU, especially Hyprland because it requires GPU acceleration to launch. nixGL should be used to address the problem.

Handling dot files

Status

Paused, until some suitable method has been confirmed to meet the requirements below.

Requirements

About handling the dotfiles, i.e. dots/, if we are doing this using Nix then the following requirements must be fulfilled.

1. Allow modifications over the existing dotfiles.

Current state of ./setup install:

• After finishing running ./setup install, users can modify any dotfiles in a traditional way, and if they run ./setup install again to update then they need to skip the steps which overwrite the targets that they have modified and later sync the upgrade manually for such targets by themselves.
  • For Hyprland, specially we have a custom folder along with ~/.config/hypr/hyprland.conf which will only get overwritten the first time but not the later times running ./setup install.
• This works but is not elegant. An experimental solution is using yaml config to store the selected behavior for each target, see #2137.

If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation.

2. Allow choosing targets.

This is similar to the above. For example user may want to use their own ~/.config/foot instead of the files under dots/.config/foot entirely.

3. Easy developing dotfiles or at least not worse than current state.

About the current state:

• @clsty: "If I were the one who develops the dotfiles, I will make changes to the local Git repo dots-hyprland and rerun ./setup install-files -f to apply the changes to observe the outcome."
• @end-4 (who develops the dots; see comment): "I modify my local copy of stuff, copy the relevant parts over, optionally selectively pick changes then commit. It's.... the most obvious way but I guess not necessarily the cleanest"

If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation.

4. Others

Find out a good method to avoid what @end-4 mentioned:

About home-manager, from my limited understanding of and experience with it, any change to the config files require a rebuild right? If this is indeed the case, switching entirely to this is not okay. Having to wait 20 seconds for each change is absurd.

Some information may help, e.g. @darsh032 commented:

I mean thats not really needed you can use mkOutOfStoreSymlink or use hjem-impure to change the configs without rebuilding

And also the "hmrice" mentioned by @Markus328 , and the flake.nix (for quickshell only) mentioned by @darsh032 .