dots-hyprland
dots-hyprland copied to clipboard
end-4
Use guix (or nix) to repack almost everything
What to "repack"?
As much as we can, including Arch/AUR packages and even some configuration files.
Benefit?
- Ability to deploy across almost all linux distros such as Arch, Debian, etc.
- P.S. You are able to use guix on NixOS, or use nix on GuixOS.
- Enhance stability and flexibility. Such packaging method allows multiple versions exist at same time, which makes dreams like #1059 possible.
- Accelerate installation speed once we provide pre-built packages in guix (or nix).
- A big "plus" version of #1017 .
Steps to achieve
- [x] Decide to choose between Guix and Nix
- [ ] ~~Learn Guix (basics only)~~
- [x] Learn Nix (basics only)
- [x] Use existing Nix/Guix packages instead of Arch/AUR ones
- [ ] Package non-existing Nix/Guix packages from Arch/AUR ones
- [ ] Provide pre-built packages
- [x] Achieve a cross-platform installation process
Nix or guix
Of course we do not need both of them. So, which one?
What is guix?
It's a cross-distro package manager, similar to nix (actually "guix" means nix written in guile) but easier to learn (?). Its configuration language, Guile, is a general programming language for many things, comparing to nixlang which is only suitable for nixos thingy.
Possible useful links
- (Lang: Chinese) https://emacs-china.org/t/nixos-nix/27803/18
- https://github.com/Evertras/simple-homemanager
- (Lang: Chinese) https://nixos-and-flakes.thiscute.world/zh/introduction/advantages-and-disadvantages https://toys.whereis.social/?search=hypr
Using Nix?
I'm trying to use Nix on Arch. But the installation process of Nix itself on non-NixOS distros is a mess and not idempotent at all. You'd better have a Btrfs snapshot before ever install it, whether you install it by using pacman or Nix official shell script.
- To solve this we may need a better installation script for Nix itself.
Using Guix?
I've tried Guix before. I didn't remember but Guix itself seems to be easily installed. However when adding Guix channel, its updating speed is too slow and I don't know what is wrong. Probably needs a powerful machine, which is not acceptable for this project.
- Still, there may be solutions, such as custom guix channel which contains only a few packages for this repo to guarantee performance.
No reason for using guix. Nix is much more popular, and even if its technically possible to combine them it is pain, so packaging to nix will benefit most users. And also it seems like the only real reason for guix existance over nix is guix devs trying to start some free software-related beef out of nowhere (nix itself is LGPL), this should not be tolerated by expanding guix package base.
No reason for using guix. Nix is much more popular, and even if its technically possible to combine them it is pain, so packaging to nix will benefit most users. And also it seems like the only real reason for guix existance over nix is guix devs trying to start some free software-related beef out of nowhere (nix itself is LGPL), this should not be tolerated by expanding guix package base.
If you've read carefully enough, you should notice that I've already listed the possible reason for not using Nix, under which condition Guix becomes the only option.
The fact is that when I installed Nix on Arch, it failed several times and each failure was breaking and blocked the next try for installing Nix again. I had to revert the whole system via Btrfs snapshot to make reinstalling possible, which is definitely a pain and mess.
Nix is popular mainly because of Nix on NixOS, which does not have problem on installing. And the issue here is for Nix on many other Linux distros.
Though I should admit that the problem could be resolved by some method I have not heard about yet, such as using another script for installing Nix on other distros which is idempotent.
@clsty that's valid but then with Guix rebuild takes a hit and the documentation and support is also limited. what if we use something like Dotbot with shell scripts then pack it using FPM.. dunno just a thought.
I have attempted to create a flake with a home-manager module to bring this to Nix using home-manager in the past, but I ultimately came to a few road-blocks that I never had the time or will to figure out to get it working so this is very rough. This configuration appears to have changed a lot since my attempt so you'll have to take what I did with a grain of salt but there's some considerations to take.
Do you intend to remove the Arch installation process entirely and use Nix for deployment everywhere? If you do then honestly you would be best off reconstructing the entire configuration in Nix using the home-manager modules for hyprland wherever possible because sourcing a normal configuration makes it pretty unworkable for the user due to the immutable nature of Nix. Using a home-manager module you can optionalize the default configuration so that it is easily modified by the user (unlike in the current process where changes to files in .config/hypr/hyprland are not kept by updates), and the user can also then add their own custom configurations without having to work with the .config/hypr/custom files. Anything which cannot be implemented using a home-manager module can be sourced or written out in a multi-line string for optionalization.
If you do not intend to remove the Arch installation or move away from the normal dotfile nature of this configuration, then you might find this useful. This just takes the entire .config directory and sources each file individually with lib.mkDefault, while ignoring .config/hypr/hyprland.conf and .config/hypr/custom. This allows the user to override any sourced file with, for example, xdg.configFile."hypr/hyprland/keybinds.conf".source = ./my-keybinds.conf. hyprland.conf is implemented using wayland.windowManager.hyprland.settings instead of sourcing the file in .config/hypr/hyprland.conf because there is a conflict where hyprland's home-manager module is itself sourcing its own default file if one is not defined in home-manager.
If you intend to move to Nix from the Arch installation process entirely, I really wouldn't recommend the latter method, but it's an option that requires relatively minimal change to the present schema. The first method has significant advantages for the user in that things can be set up to be finely customizable and not break changes that happen in future updates to this configuration. That said, it might be possible to use the latter option as a stop-gap for transitioning away from being a normal dotfile config towards writing more of it out in Nix. With hyprland.conf being implemented with the home manager module rather than being sourced, it should be possible to add on top of current configuration with wayland.windowManager.hyprland.settings.
I am willing to help out, although it has been a bit since I've done much with Nix because I've been busy.
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.
Having to wait 20 seconds for each change is absurd.
Welcome to build system world
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.
Well, I suppose there is a way to avoid home-manager. You can create a sort of meta package where you can define the required dependencies, and just use a shell script to install the config as is currently being done with the arch process. Doing it this way you lose pretty much every benefit of nix besides the fact that it can install packages across multiple distros. I guess that's fine if that's all you want.
The stated benefit
Enhance stability and flexibility. Such packaging method allows multiple versions exist at same time, which makes dreams like https://github.com/end-4/dots-hyprland/issues/1059 possible.
is pretty much dependent on the fact that nix provides atomicity through the declarative method by which it is deployed. There is no way to simply swap out home configurations without using home-manager, because home-manager uses nix to copy the generated configuration to the immutable /nix/store and it symlinks a reference in the user's home directory to the store.
I should also note, Nix has a bit of an gpu acceleration problem when used on non-NixOS distros. We can use nixGL to run OpenGL programs (like Hyprland), but it's not perfect. That said, it might be a reason to keep using as many specific distro packages as possible and not fully integrate Nix, especially given the GUI-heavy nature of something like this.
It might be that Nix cannot be the silver-bullet solution to what you're trying to achieve, but it probably could at least be somewhat functional for people who don't use Arch. I'll see if I can try and whip up a draft in the coming days for the less integrated approach.
I've managed to set up the config files using Nix/Home Manager on my Fedora machine. Yes, migrating to Nix is quite challenging and time-consuming, but in the end, it offers a powerful way to distribute configurations across virtually any Linux distro—essentially making them distro-agnostic.
In my opinion, Nix is a better option than Guix because it's more widely adopted across open-source projects. Even if a repository doesn't include a flake.nix file, you can create one yourself, in that way you could build the project from the ground up. That's one of the reasons Nix has such a large package ecosystem. And to me, that's the most appealing part of Nix—it's not just a package manager, it's a full-fledged build tool.
I'm trying to use Nix on Arch. But the installation process of Nix itself on non-NixOS distros is a mess and not idempotent at all. You'd better have a Btrfs snapshot before ever install it, whether you install it by using pacman or Nix official shell script.
* To solve this we may need a better installation script for Nix itself.
Determinite nix installer overcomes this problem.
Here is my setup for reference.
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.
If you want to manage your config files entirely with Home Manager. But, like in my case, you could just symlink the config files to avoid that inconvenience.
Determinite nix installer overcomes this problem.
I guess you meant https://github.com/DeterminateSystems/nix-installer , right? I should have a look at it when possible.
Determinite nix installer overcomes this problem.
I guess you meant https://github.com/DeterminateSystems/nix-installer , right? I should have a look at it when possible.
Yes
I’m not an expert on Nix—I’ve only recently migrated to it. This tool was key in making the transition easier for me.
Before switching, I did some research and found many complaints about installing Nix on non-NixOS distributions. Then I came across the video Getting Started with Nix Home Manager that recommended this tool.
For anyone looking to migrate to Nix, I highly recommend watching this video. You might ask, 'But this video is about Home Manager.' Yes, it is—Home Manager and Nix are practically inseparable. Home Manager lets you manage both your packages and configurations in a much more structured way. It also provides predefined options that make it easier to configure certain aspects of the programs installed with Nix.
But, like in my case, you could just symlink the config files to avoid that inconvenience.
Simply symlinking the config files doesn't really avoid that inconvenience so much as it just ignores the problem. Symlinked config files are immutable – they cannot be edited at all.
Like I said, the other solution would be to recursively symlink all files individually with lib.mkDefault so that the user can provide a replacement source file of their own, or disable the sourcing of that file entirely so it can be handled within the user's directory. Regardless, if a user wants to remove the file from being sourced there will have to be a rebuild at that moment. I have a reference implementation for the logic to symlink all the files individually working, but I haven't had the chance to get around to fully implementing everything else required to get this working with Nix.
Like I said, the other solution would be to recursively symlink all files individually with
lib.mkDefaultso that the user can provide a replacement source file of their own, or disable the sourcing of that file entirely so it can be handled within the user's directory. Regardless, if a user wants to remove the file from being sourced there will have to be a rebuild at that moment. I have a reference implementation for the logic to symlink all the files individually working, but I haven't had the chance to get around to fully implementing everything else required to get this working with Nix.
But you are copying the files inside a folder into the Nix store, then symlinking them to the respective paths. In this way, every time someone wants to edit the actual config file, they have to rebuild the Nix config. Nix handles the config files and the symlinks.
In my case, I just symlink my config files inside a folder to the respective paths using mkOutOfStoreSymlink, so that I don't have to rebuild my Nix config every time I make a change. Nix only handles the symlinks. I know this way you're taking the config files out of Nix's control, and Nix won't track any changes to your config. But it's not a problem if you're using Git—in this case, we already keep track of config files with Git.
Symlinked config files are immutable – they cannot be edited at all.
Didn't understand this part. I can edit my symlinked files.
As I said earlier, I'm not an expert—maybe I'm missing something. If you haven't checked my approach here, please take a look and give me some feedback.
Update (2025.09.10):
I have been busy for last several months and still are currently.
I've reinstalled Linux on my laptop, switched the distro from Arch Linux to Debian Linux 13 (trixie). And I've also installed nix using Determinite nix installer.
The next thing I'll do is gradually learning Nix (on debian) following the tutorial Evertras/simple-homemanager.
I hope I can make it in this year.
Update (2025.09.18): I've done learning Evertras/simple-homemanager but it seems not enough at all. For the next thing I'll learn more following the guide NixOS & Flakes Book.
Update (2025.09.22): I've been using Hyprland and other packages installed via home-manager for a week. Hopefully I should be able to migrate all user-space packages needed into my Nix config.
Although there's one thing that Nix package which uses pam will not work, for example swaylock (and hyprlock too I guess), see https://github.com/NixOS/nixpkgs/issues/128523#issuecomment-1086106614
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.
I mean thats not really needed you can use mkOutOfStoreSymlink or use hjem-impure to change the configs without rebuilding
I think the best of the worlds would be a fully and entirely port of the dots to Nix (all configs or some part of them), allowing declarative configuration and the use of hmrice (see the issue, I have a fork, this repo seems abandoned) that works fine for ricing, and will allow you to write the module as any other.
For the first example, I'm working for a Nix port of caelestia-dots, here is the repo. Just simply fetching the dots from the caelestia-dots/caelestia repo will destroy half of the advantage of using Nix
@clsty Where do we start contributing on this issue, like a repo you created to specially work on this where we can contribute instead of creating our own paradigm, I and many others are more than happy to help on this.
Just simply fetching the dots from the caelestia-dots/caelestia repo will destroy half of the advantage of using Nix
Yeah nix's functional way of doing even the most trivial thing like toml is pretty cool but translating the whole dotfiles is a big project and would require a lot of maintaining later, I think a better approach would be to do something like what soramane did split the bar and dotfiles and make another repo for the bar with a flake.nix in it to let users use it without much hassle in their own dotfiles
Just simply fetching the dots from the caelestia-dots/caelestia repo will destroy half of the advantage of using Nix
Yeah nix's functional way of doing even the most trivial thing like toml is pretty cool but translating the whole dotfiles is a big project and would require a lot of maintaining later, I think a better approach would be to do something like what soramane did split the bar and dotfiles and make another repo for the bar with a flake.nix in it to let users use it without all much hassle in their own dotfiles
Yeah, splitting the quickshell config and the dots would be great, and translating the whole dotfiles would be done once, the biggest trouble is to keep up to date anyway. Splitting the shell is almost a pre requisite to this being viable (the shell likely updates much more?)
Nix with home-manager can handle two parts:
- Dependencies
- Note: 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.
- Configuration files
Configuration files
Let's just press the pause button, until I've learned home-manager enough and we find out a good method to avoid what @end-4 mentioned:
Too long, click to toggle expand
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.
I've also noticed some information provided may help, e.g. @darsh032
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 .
Thanks for the information but I still lack knowledge and experience about home-manager handling the dot files.
If you're interested, my learning roadmap is here (just 2 steps):
- (Now doing) Learn Nix lang basics and rework a quick guide written in Chinese as invited here
- Learning Nix flakes and home-manager using NixOS & Flakes Book | Home Page
Dependencies
We could do it now, i.e. not install them by pacman (or AUR helper), but by home-manager.
@clsty Where do we start contributing on this issue, like a repo you created to specially work on this where we can contribute instead of creating our own paradigm, I and many others are more than happy to help on this.
I apprieciate your contribution a lot. Please read the comments in dist-nix/install-deps.sh about how you may help.
P.S. I'm not sure but does Hyprlock must be the same version as Hyprland?
Let's just press the pause button, until I've learned home-manager enough and we find out a good method to avoid what @end-4 mentioned: Too long, click to toggle expand
You kind of can't leave the rebuilding thing if you're not using normal dotfiles like hyprland.conf instead of the nix version which gets translated into the hyprland.conf at the normal path ~/.config/hypr, and that woul require a rebuild.
Futher details on folder iiqs-hm:
- 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.
- This probably only happens for Debian(-based) distros though, see https://github.com/NixOS/nixpkgs/issues/128523#issuecomment-1086106614
- See also https://github.com/caelestia-dots/shell/issues/668
- On non-NixOS distros, packages installed via home-manager have problem accessing GPU, especially Hyprland because it requires GPU acceleration to launch.
nixGLshould be used to address the problem. Example code I'm using in myhome.nix:
{ config, lib, pkgs, nixgl, ... }:
{
nixGL.packages = nixgl.packages;
nixGL.defaultWrapper = "mesa";
# other lines not showed here ...
home = {
packages = with pkgs; [
cowsay # normal packages that does not need nixGL
lolcat
# other lines not showed here ...
]
++ [
(config.lib.nixGL.wrap pkgs.firefox-bin)
(config.lib.nixGL.wrap pkgs.hyprland)
# other lines not showed here ...
];
# other lines not showed here ...
};
}
And in flake.nix:
{
inputs = {
nixpkgs.url = "nixpkgs/nixos-25.05";
home-manager = {
url = "github:nix-community/home-manager/release-25.05";
inputs.nixpkgs.follows = "nixpkgs";
};
hyprland = {
url = "github:hyprwm/Hyprland";
};
nixgl.url = "github:nix-community/nixGL";
};
outputs = { nixpkgs, home-manager, nixgl, ... }:
let
lib = nixpkgs.lib;
system = "x86_64-linux";
pkgs = import nixpkgs {
inherit system;
overlays = [ nixgl.overlay ];
};
in {
homeConfigurations = {
mydot = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
extraSpecialArgs = { inherit nixgl; };
modules = [ ./home.nix ];
};
};
};
}
Note: 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.
I guess I will have to have some sort of detection for this if it's the case? Currently Quickshell is used for the lock and Hyprlock is only a fallback, and I'm guessing it would be reasonable to install Quickshell with Nix since in theory it's the most unstable one...
Let's just press the pause button, until I've learned home-manager enough and we find out a good method to avoid what @end-4 mentioned: [...]
One problem when I was trying to use NixOS was that the build coupled system stuff and home stuff together, so a user config change would also cause Nix to re-evaluate everything (though if we generalize this, it's just how Nix builds are). I'm not sure if it makes a large difference when they are on their own. Not every Nix user I know agree on whether or not to separate them.
P.S. I'm not sure but does Hyprlock must be the same version as Hyprland?
If this is a Nix question, I'm not sure. As a general design/functionality question, should be fine, I don't see any problem with that
One problem when I was trying to use NixOS was that the build coupled system stuff and home stuff together, so a user config change would also cause Nix to re-evaluate everything (though if we generalize this, it's just how Nix builds are). I'm not sure if it makes a large difference when they are on their own. Not every Nix user I know agree on whether or not to separate them.
Uhm I think we'll be passing the flakes as a module instead of the whole system configs with users bundled so its kind of the users job to keep his or her's system config error-free plus we can use home-manager seperate from nixos so like using home-mangaer switch for hm stuff
So... the huge build time problem is the user's problem and we can't do anything... right? Wait, but we also have dependencies... they could be considered "system" (non-config) stuff that shouldn't need to be reconsidered on every config change(?)
So... the huge build time problem is the user's problem and we can't do anything... right? Wait, but we also have dependencies... they could be considered "system" (non-config) stuff that shouldn't need to be reconsidered on every config change(?)
By system I meant the root stuff like bootloader, and yes we can solve the huge build time problem with cachix.
@end-4
One problem when I was trying to use NixOS was that the build coupled system stuff and home stuff together, so a user config change would also cause Nix to re-evaluate everything (though if we generalize this, it's just how Nix builds are). I'm not sure if it makes a large difference when they are on their own. Not every Nix user I know agree on whether or not to separate them.
I'm using HM aka home-manager on debian 13 and I am pretty sure that we can use HM to evaluate dependencies only (see the example above, the cowsay lolcat firefox-bin hyprland are all nix packages), and still use the dots inside ~/.config just as what we did before. We only run HM manually so it will not re-eval unless we want to.
Not every Nix user I know agree on whether or not to separate them.
The repo here is for Arch users only. We want it for probably any Linux users after this issue being addressed, i.e. we are not making this repo only for Nix(OS) users.
For general Linux users, using Nix to install the dependencies just means convenience cuz they do not need to find dependency on their distros which equal to the Arch/AUR ones anymore.
And it also does no harm to the Arch users like myself. Its OK if they want to use pacman or AUR helper to install other packages.
And I just realised that some AUR packages are really unstable and very likely to break due to dependency version requirements thingy if we use it for long period of time (do you remember why we switch to Arch repo instead of -git from AUR for Hyprland?), and HM seems to be much stabler than AUR in terms of installing packages.
If some Nix user wants to use HM to include the configuration files, they can do it themselves. We do not need their agreement cause we are not removing any feature that we provided before anyway.
I guess I will have to have some sort of detection for this if it's the case? Currently Quickshell is used for the lock and Hyprlock is only a fallback, and I'm guessing it would be reasonable to install Quickshell with Nix since in theory it's the most unstable one...
@end-4 If quickshell is installed via Nix then it cannot be used as a screen lock on non-NixOS distros (The actual problem is some distros like debian has their own @include extension for PAM configuration which cannot be recognised by Nix-installed screenlock. So I guess some distros like Arch is probably still OK? Not sure.). So, yeah we need another screenlock. Let's let user to decide, make the screenlock executable a configurable option, and use swaylock by default cuz its common in every distro. (Not every distro have Hyprlock using system package manager though, for example I can not install it using apt on debian13.)