Using eww with home-manager

[eclairevoyant]

I'm using home-manager on Arch Linux without flakes (from the nix community) to manage my eww config files.
With home-manager, config files are put into the "nix store" and symlinked from wherever (in my case, ~/.config/eww/eww.yuck) to the nix store (/nix/store/[hash]/eww.yuck), where [hash] will change frequently.

Based on this piece of code, it seems that eww hashes the (real) path to the config file to decide naming for the IPC socket. With nix, this path changes regularly (i.e. whenever I edit the config file and create a new derivation). This leads to all eww commands failing, because it can't find a nonexistent socket associated with the new store, but eww is already running so it can't update the existing process.

Is there a way to get eww and home-manager to work together with each other?

[viandoxdev]

With the current code I'd assume its impossible, unless you can get home manager to fix the path of your eww config. I don't really see a way to easily keep the symlinked path tho, since the path canonicalized (resolves symlinks) the path and not doing it would break relative paths: -c ./eww from ~/.config would be different from ~/.config/eww. Using something like path-clean (normalizing) instead could be a solution tho.

So either patch eww to normalize instead of canonicalize, or fix the eww path in a way or another (I don't know anything about home manager, there might have a work around)

[Shados]

Yeah, if the canonicalization of the config directory path is dropped, it should work fine. Not clear to me why the config directory path should be canonical here, instead of merely normalised, although I'm guessing it's because Rust's stdlib still doesn't have a Path::normalize function. cargo-util has an appropriate function, internally used by Cargo.

As a work-around on the home-manager side of things, you could try this: programs.eww.configDir = config.lib.file.mkOutOfStoreSymlink "~/.config/eww". This will result in the symlink chain HM produces pointing directly to the out-of-Nix-store configuration directory, instead of copying the directory into the store. Upsides: the canonical path is now stable, and you can edit config files directly and get the benefit of live config reloading. Downside: your eww config is no longer synchronised to the active HM generation.

[eclairevoyant]

Thanks, this worked well for me; I ended up removing the quotes and pointing to where I stored my eww config:

programs.eww.configDir = config.lib.file.mkOutOfStoreSymlink ./path/to/eww/config/folder;

[eclairevoyant]

Also yeah, I'm not sure why they need to hash the config location (whether normalised or canonicalised or w.e) to determine the IPC socket name, maybe there's a use case for this that I haven't anticipated? But I can't think of a reason to run multiple instances of eww simultaneously

[viandoxdev]

Also yeah, I'm not sure why they need to hash the config location (whether normalised or canonicalised or w.e) to determine the IPC socket name, maybe there's a use case for this that I haven't anticipated? But I can't think of a reason to run multiple instances of eww simultaneously

All variables are global, same for windows and widgets (also classes) for now, so you're bound to get name collisions on big enough configs. They're might also be performance issues, but I never measured so I can't guarantee that.

It's also probably that, because the config path is an option, keeping a single instance would add quite a lot of complexity (either merging the configs somehow, or creating some sort of scope).

A workaround would be being able to manually set the IPC socket path in a file or through a flag, not sure about it tho.

[eclairevoyant]

Fair enough, I don't know rust (other than reading code) to be able to patch in a new flag or option like that, but the current workaround works well for my situation. Thanks for explaining the use case!