Conversation
Created home manager module that sets up wayle as a systemd service and allows for wayle to be configured in nix.
|
Just a quick question @isaacST08, did you use AI? How much? |
I didn’t use any AI. Every single character is hand typed. |
PerchunPak
left a comment
PerchunPak
left a comment
There was a problem hiding this comment.
Since you did not use AI, I feel terrible to close this... I already have a prepared PR to nixpkgs for wayle, but we should open it after a release, since it is still unusable for an average user (fresh PRs get much more attention than PRs that were draft for months).
In the current state of wayle, it doesn't make much sense to make flake.nix right now and then migrate it to nixpkgs. We will also need to maintain backwards compatibility for this flake.nix
But I can help you improve in Nix by correcting some mistakes, there are a couple of things I can teach you. I still appreciate your work and probably will use your home-manager module for a PR
|
Okay, I was wrong about this being unusable. I tested this a couple month ago when wayle did not have pop-ups implemented. But I am still not sure if this project is ready. @Jas-SinghFSU, is it ready for an average user? |
|
@PerchunPak I am close to finishing the dashboard dropdown (just doing cleanup, review, performance analysis and fine tuning). It should be done either today or tomorrow. Then I’ll focus on notifications and OSD. Once those are done we should be good. I don’t feel comfortable releasing without notifications working and OSD is a quick fast follow to that. The settings dialog is the final step but everything is configurable via config.toml so that isn’t really a release blocker. |
|
I will start daily-driving this anyway |
That’s ok. It was my intention that a flake could be used in the interim until the package and module are available from nixpkgs/hm. At that point I see no reason why the flake couldn’t be depreciated. I didn’t realize that a nixpkg PR was already underway, I just assumed it would be a long way out and just hoped to get something going to then make migrating to nixpkgs easier.
I would love any feedback or teachings you have for me. I’m always happy to learn more about nix. The home-manager module is quite simple in my opinion but I’m happy to hear that it at least should be useful. |
nix/modules/home-manager.nix
Outdated
| }; | ||
|
|
||
| settings = mkOption { | ||
| type = lib.types.attrs; |
There was a problem hiding this comment.
It is possible to define the option type as TOML
| cargoHash = "sha256-Y/R8iI1sIHZxqxlPO1iTIqpLJGkCuTPAmh2OarvkoVA="; | ||
|
|
||
| LIBCLANG_PATH = lib.makeLibraryPath [llvmPackages.libclang]; | ||
| LD_LIBRARY_PATH = lib.makeLibraryPath [ |
There was a problem hiding this comment.
It is discouraged to set LD_LIBRARY_PATH directly in Nix, you should instead put dependencies into buildInputs or nativeBuildInputs (the former is for runtime dependencies and the second one is for build-only time dependencies)
There was a problem hiding this comment.
Ok, good to know that it is discouraged. I remember something happening that meant that even if the package was in either of the build inputs, it still failed until I added it to LD_LIBRARY_PATH. I will look into your package implementation and see if I can find what you did differently to avoid this.
There was a problem hiding this comment.
Just as a side note, I started with a nix shell and then went to a package. I started by following https://nixos.wiki/wiki/Rust#Installation_via_rustup . They use LD_LIBRARY_PATH, is this only acceptable because it is a shell or should the wiki get a note mentioning this?
There was a problem hiding this comment.
Yes, it is allowed in nix shells. buildInputs make sense only for packages, since you don't build anything in a shell, just putting packages into $PATH
|
|
||
| # This test is broken because wayle is not given access to hyprland in the | ||
| # nix sandbox. | ||
| "--skip=new_fails_when_hyprland_instance_signature_missing" |
There was a problem hiding this comment.
I am not sure why, but that test passes in my package
There was a problem hiding this comment.
Again, I will look into your package to see what you’ve done differently. Maybe it is caused by something else existing or not existing on my machine compared to yours.
There was a problem hiding this comment.
Maybe it is caused by something else existing or not existing on my machine compared to yours.
Nix is notoriously strong about enforcing reproducibility, so it is pretty impossible. Unless drivers, kernel or something similar mess up something (which is not the case here).
Packages in nativeBuildInputs may register some hooks, so it is probably the reason (you put most packages in the LD_LIBRARY_PATH while I used nativeBuildInputs).
There was a problem hiding this comment.
As mentioned below, this test is still failing on my system even when I use your package.
| export BINDGEN_EXTRA_CLANG_ARGS="$(< ${stdenv.cc}/nix-support/libc-crt1-cflags) \ | ||
| $(< ${stdenv.cc}/nix-support/libc-cflags) \ | ||
| $(< ${stdenv.cc}/nix-support/cc-cflags) \ | ||
| $(< ${stdenv.cc}/nix-support/libcxx-cxxflags) \ |
There was a problem hiding this comment.
There is rustPlatform.bindgenHook. If you are not sure how to do something, try grepping nixpkgs. bindgen is definitely used in at least one other package, so you should find the solution there. That applies to pretty much everything
~/dev/nixpkgs $ rg --files-with-matches buildRustPackage | xargs rg bindgen
<301 results>
| postInstall = '' | ||
| # Generate wayle icons and copy them to the correct nix directory. | ||
| mkdir -p $out/share | ||
| $out/bin/wayle icons setup |
There was a problem hiding this comment.
Jas said that this command just does cp -r $src/resources/icons ~/.local/share/wayle/icons; not to blame you for not knowing though
https://discord.com/channels/1277526090516135978/1277527251189240000/1470198152312262906
There was a problem hiding this comment.
Yeah I didn’t know this, I just thought I’d follow the build instructions in case something special was going on.
|
|
||
| 3. Translate your new config from the TOML syntax of the | ||
| `~/.config/wayle/config.toml` file into nix syntax in your `home.nix` file at | ||
| `services.wayle.settings = { # settings go here }`. |
There was a problem hiding this comment.
BTW you can automate this using
$ nix repl
nix-repl> :p builtins.fromTOML (builtins.readFile ./config.toml)
{
bar = {
layout = [
{
center = [ "window-title" ];
left = [
"hyprland-workspaces"
"cava"
"media"
];
monitor = "*";
}
];
};
}There was a problem hiding this comment.
This is amazing to know, thank you.
| **CAUTION:** Home manager will automatically move any existing config to a | ||
| `config.toml.hm-bak`, or similar, backup file name. This is expected, however, | ||
| wayle will automatically create a _new_ `config.toml` file if you moved the | ||
| symlink make by home-manager and didn't move it back. If this occurs, |
There was a problem hiding this comment.
For me, home-manager just crashes and doesn't update symlinks at all. Maybe there is a setting?
There was a problem hiding this comment.
I have home-manager configured as a module in my main flake and I have the following option set in its config:
# Inside "inputs.nixpkgs.lib.nixosSystem {...}":
modules = [
...
{
inputs.home-manager.nixosModules.home-manager
{
home-manager = {
...
backupFileExtension = "hm-bak";
...
};
}
}
...This must be the difference that causes your homemanager to fail to take over and generate the symlinks. However I don't have an easy solution for users who don't want to set this option because wayle seems to automatically generate a new file at any opportunitiy which will need either backing up or removing manually without the option.
| This nix package will automatically install the icons for you so you don't need | ||
| to worry about running `wayle icons setup`. | ||
|
|
||
| ##### Live Config Reloading |
There was a problem hiding this comment.
I would consider this section a bit redundant since this is unfortunately the case for every software in Nix, and it cannot be fixed. Thus, every user already knows how to work around that. If the user already managed to climb Nix's learning curve...
There was a problem hiding this comment.
Yes I suppose that is true. I think I was possible just trying to soften that curve a little bit, even if it was just for a handful of people.
That graphic is also fantastic.
|
@PerchunPak I've just tried to install wayle via your nix package and it fails to build with: I can only assume that you aren't getting any errors like this. Are there any extra details you are adding to your config when testing? |
Yeah, the test is broken on main right now. I am using an older version of wayle currently. I have pushed a new version, but didn't test the build (will do it later today) EDIT: I am talking about |
|
Are you sure you are not running the build with Also are you on x86 or ARM? |
I am sure I am not using impure. The output of
I am on x86. |
I've just tried this new commit and it successfully built. I'm getting some other errors after running wayle but I don't yet know if those are nix related yet. |
|
Everything seems to be working on the nix side. I definitely have some more ideas for the hm module now that I have properly played around with wayle and configured it a bit. I will also be daily driving it now going forward. @Jas-SinghFSU I've found a couple of bugs while configuring, would you like me to create issues now or would you rather I wait until you've finished up the rest of the features in case they get resolved naturally? |
|
@isaacST08 I'd favor that we create the issues now. Worst case scenario we just close them if they're already fixed. |
Like what? |
Are you sure? That commit didn't skip 3 other failing tests. Jas fixed those today and this commit definetly compiles (at least on ARM, compiling for x86 right now) |
For example, by referencing the users config, if the wallpaper engine is set to be enabled, then swww/awww gets installed, and likewise depending on the theme provider that is set, that gets installed as well. So if the theme provider is set to matugen, then matugen gets installed for the user. That way the required dependencies get installed automatically without bloating the system with unnecessary programs. |
That’s quite odd. But yes, it worked just fine. It built with no modification and I used it for a good few hours with no blatant issues. Or perhaps some of these issues were the bugs I ran into. I will check again with the new commit before I make any issue reports. But regardless, yes, it built with no failed tests. |
|
@PerchunPak I've created a HM module for wayle (hopefully correctly this time). I haven't created a PR for it yet because of what you said about fresh PRs getting more attention. I'd highly appreciate your feedback and if you do try it please let me know if anything breaks. |
|
Cool! Can you add it to this PR? I have a couple of comments |
|
I just copied it over directly. I haven't explicitly checked if it will work directly with this flake. Comment away! |
PerchunPak
left a comment
PerchunPak
left a comment
There was a problem hiding this comment.
Love the idea of automatically installing required dependencies, much better than including everything possible in the buildInputs, like I did with hyprpanel
nix/modules/home-manager.nix
Outdated
| # Main config file. | ||
| xdg.configFile."wayle/config.toml" = mkIf (cfg.settings != { }) { | ||
| source = tomlFormat.generate "wayle-config" cfg.settings; | ||
| force = true; # Wayle aggressively produces its own config file. |
There was a problem hiding this comment.
It used to be true for hyprpanel, but I did not encounter this problem with wayle
| force = true; # Wayle aggressively produces its own config file. |
There was a problem hiding this comment.
I've personally had this problem quite a bit. I don't like the solution of forcing either. I think if we were to not use the force flag then we would need an assertion that the file isn't already there, accompanied by a very clear error message for when (I don't think it's a matter of "if") it fails.
There was a problem hiding this comment.
I've personally had this problem quite a bit.
Did you use wayle config set?
I think if we were to not use the force flag then we would need an assertion that the file isn't already there, accompanied by a very clear error message for when (I don't think it's a matter of "if") it fails.
Unfortunately, this is not possible. home-manager tries to get a nice error message, but it is only accessible in the journalctl logs, which is IMO not an obvious place to find an explanation
There was a problem hiding this comment.
Did you use
wayle config set?
Nope. Wayle has just been really trigger happy at making a new, blank config file. Granted, it usually happens when I move/copy the symlink so that I can edit the config without rebuilding nix. But I know that the issue is so I can quickly fix it. But I would really like to remove any potential headaches from other nix users if possible.
Unfortunately, this is not possible. home-manager tries to get a nice error message, but it is only accessible in the journalctl logs, which is IMO not an obvious place to find an explanation
I was afraid this would be the case.
I don't have a good solution for this then. I think the only thing left would be to let the user decide whether to enable to force flag or not. I guess it's just a question of what to make the default for wayle and use mkDefault if we decide the default should be to force.
There was a problem hiding this comment.
Nope. Wayle has just been really trigger happy at making a new, blank config file. Granted, it usually happens when I move/copy the symlink so that I can edit the config without rebuilding nix. But I know that the issue is so I can quickly fix it. But I would really like to remove any potential headaches from other nix users if possible.
I have two commands just for that
(pkgs.writeShellScriptBin "modify" ''
set -ex
mv "$1" "$1"1
cat "$1"1 > "$1"
'')
(pkgs.writeShellScriptBin "modifyu" ''
set -ex
mv "$1" "$1".modified
mv "$1"1 "$1"
'')$ modify config.toml
+ mv config.toml config.toml1
+ cat config.toml1 > config.toml
$ modifyu config.tom
+ mv config.toml config.toml.modified
+ mv config.toml1 config.tomlIt is really annoying how long nix rebuilds are. Anyway, we don't want users to lose their modified configs accidentally, that's why force is off by default
nix/modules/home-manager.nix
Outdated
| tomlFormat = pkgs.formats.toml { }; | ||
| in | ||
| { | ||
| meta.maintainers = with lib.maintainers; [ isaacST08 ]; |
There was a problem hiding this comment.
| meta.maintainers = with lib.maintainers; [ isaacST08 ]; | |
| meta.maintainers = with lib.maintainers; [ | |
| isaacST08 | |
| PerchunPak | |
| ]; |
There was a problem hiding this comment.
I don't see you in the home-managers maintainers list, so you'll need to make sure you add your information to that.
I turned on issues on my home-manager fork so feel free to add any comments there directly or make a PR so that your git contributions are actually recorded.
There was a problem hiding this comment.
There was a problem hiding this comment.
I turned on issues on my home-manager fork so feel free to add any comments there directly or make a PR so that your git contributions are actually recorded.
The only contributions that count towards getting permission to merge PRs are created and reviewed PRs, so it doesn't really matter.
There was a problem hiding this comment.
I am actually
My appologies, I didn't realize that there were two lists, I only searched in modules/lib/maintainers.nix. My bad.
nix/modules/home-manager.nix
Outdated
| (lists.optional (elem themeProvider [ | ||
| "matugen" | ||
| "wallust" | ||
| "pywal" |
There was a problem hiding this comment.
wallust and pywal have home-manager modules, we should probably enable them instead of just adding them to home.packages
There was a problem hiding this comment.
Yes, I'm aware. I don't know how they might conflict with each other though and I found that they seemed to work sufficiently with just the package.
It might be required that either the settings from the wallust/pywal modules get translated and applied to the settings for wayle, or vise versa. I also don't know which direction is best.
Additionally, I don't know if when the wallust or pywal home-manager modules are enabled if they even need to be enabled in wayle's config at all. TBH, I don't know exactly how wayle interfaces with these tools so some experimentation might be required.
Additionally, there should probably be a way to let the user choose the package that gets installed for matugen but just default to using the one from pkgs.
There was a problem hiding this comment.
You are right, pywal module does some additional stuff (adds integration to kitty, xterminal, etc). Adding binaries is enough. Though it would be good to have an autoInstallDependencies. It is hard to remove something from a list in nixos modules
Actually, the proper way to do this is create a wrapper around wayle with additional dependencies, but it is very complicated and inconvenient. I don't know a good way to do that yet
Jas-SinghFSU
force-pushed
the
master
branch
4 times, most recently
from
9da844e to
232bfd8
Compare
|
@isaacST08 Jas approved opening a PR to nixpkgs, so I think it is time for you to open a PR to home-manager. But apply the suggestion above first please (The PR should be draft until wayle is merged into nixpkgs) |
|
@PerchunPak if everything looks good to you, I’ll open a draft PR for home-manager later today. |
Everything looks good and works; thank you for your work. Yes, please open a PR |
|
@PerchunPack if I could request a little bit of advice since you've contributed to home-manager before: One of the checks is running Should I still create the PR as a draft regardless? Any hints as to why the tests even on master would be failing? |
Yes, create the PR. Running all tests is unnecessary, and those are very heavy; I don't know why running everything instead of things that were touched is in the PR template. |
I've been meaning to get to that for GH actions. My baby-steps to getting there so far have failed. |
|
I mean home-manager tests, not wayle |
|
Gotcha, both still stand true though I suppose. |
|
Home-manager PR made. |
was renamed to ; applied this change to the the systemd startup command.
|
I noticed the |
|
Yes, it was renamed. I think we can close this, since both home-manager PR and nixpkgs PR are open |
4 participants
This will not be merged
Nix support will be added directly to nixpkgs, without flake.nix in this repo. See NixOS/nixpkgs#503416
Created a NixOS package and home-manager module so that wayle can be easily installed and configured using NixOS.
What was added:
wayleandwayle-shellcli commands.home.nixfile.README.mdfile was updated to include how to install wayle by using the nix flake.Going forward:
I am almost certain that this will package will break as wayle is developed simply due to how early into development wayle is. Regardless, I thought that it would still be a good idea to get this started sooner rather than later.
If you do accept this PR, please do not hesitate from doing something that will improve wayle or adding a dependency
with the fear of breaking this nix package/flake. This packaging can be updated and, should something break, you are more than welcome to contact me requesting that I fix it.