allow imperative usage with home-manager module #68
Conversation
|
I'm not sure i understand the |
A path that gets inserted before every template output_path |
|
I'll start working on it. |
|
I've been trying but the paths on windows are kinda weird, I gotta install nixos back first. |
|
I forgot to mention this PR when i added the |
|
I tried picking this up again but it seems that there's something wrong with the
matugen image /nix/store/h9wzjbpllh2s7lww0adpqfs9szvyqp8r-simple-blue-2016-02-19/share/backgrounds/nixos/nix-wallpaper-simple-blue.png --config /nix/store/kkr8q14s48qhx6xh1j1s3yjrymnajgmh-config.toml --prefix /nix/store/2y0mshl6qs2ppikqfwm0qbf032vz7fsw-resultswith this config I get which is really weird because the script should never access that path. Note that this was ran in the nix environment so matugen probably has some issues accessing $HOME now when I manually execute the command I get when I remove the prefix it works. here's the backtrace: |
|
I think I fixed it. I'll also add some warnings when you try to write to root and matugen isn't running with elevated privileges. |
DaniD3v
force-pushed
the
main
branch
3 times, most recently
from
dc840f3 to
e8a5324
Compare
|
I deviated a little bit from my original plan. Now we're using an activation script to basically just run matugen in the home-manager activation script. This is kind of ugly because it makes the system have state. The flake can still be pure because only the activation script has to be reproducable tho. Why I went with the activation script
AlternativesI was thinking about using home-manager specializations. They are probably the best way to do this, however they're not yet stable Reasons for Specializations:
Downsides:
Sorry abt not using the --prefix option in the end. I only came up with the method of putting matugen in the activation script after re-designing the whole PR. I still left a commend in there fixing the option (again). I you're worried about minimal PRs I can remove it. |
|
Looking very much forward to this getting merged, thanks for implementing! |
|
I forgot to update the README. I'll also make a PR to the Wiki once I'm ready. |
|
If anyone wants to try this (for reviewing) here's some snippets from my current configuration. programs.matugen = {
enable = true;
settings = {
config = {
reload_apps = true;
reload_apps_list = {
gtk_theme = true;
kitty = true;
dunst = true;
};
};
};
wallpaper = "${pkgs.nixos-artwork.wallpapers.simple-blue}/share/backgrounds/nixos/nix-wallpaper-simple-blue.png";
};
programs.matugen.templates.firefox = {
input_path = ../../external/templates/colors.json;
output_path = "${config.xdg.cacheHome}/wal/colors.json";
};
programs.matugen.templates.gtk = {
input_path = ../../external/templates/gtk.css;
output_path = "${config.xdg.configHome}/gtk-4.0/gtk.css";
};Don't forget to change your flake input to # replace once `https://github.com/InioX/matugen/pull/68` gets merged
matugen.url = "github:DaniD3v/Matugen/" |
Originally posted by @AtomicTroop in #65 (comment) you're probably interested in this as well |
|
I tried using the module, but when i enable the option If i disable the option, the activation is working as expected. |
|
Gave this a try too. Basic configuration worked as expected and initial rebuild updated my colorschemes correctly. Not sure what's going wrong, will have to dig into this later tonight. |
|
Turns out the issue was in fact not activation related, but a combination of two wallpapers producing the same (default?) colorscheme and I guess during activation I would need to point to swww's executable directly but matugen doesn't support this I think? On a related note, I'm also getting the I tried explicitly disabling the gtk reload functionality, but it seems to have no effect here. The relevant lines from my generated config: Edit: I don't think the default for these values should be |
|
You could try pointing to the executable directly inside a hook as a quick test. [templates.foo]
# ...
post_hook = "<sww command> {{ image }}"I could also add config options to set program paths. As I was refactoring the code, I started thinking about rewriting the whole reload section anyways, pretty sure it was written in a rush. |
|
I just realized that the For example, you could have swww "installed" but not in your path because you I think I'll move these options out of The issue is that the user could have some version conflicts by, for example, I'll override the default for the This would also make the code a bit cleaner because we can use (This is the struct I'm talking about) #[derive(Deserialize, Serialize, Debug)]
pub struct Apps {
pub kitty: Option<bool>,
pub waybar: Option<bool>,
pub gtk_theme: Option<bool>,
pub dunst: Option<bool>,
} |
|
I think leaning into the pre/post hooks and removing the whole By taking this approach, you'd also work around this whole activation script path issue as the responsibility for providing an absolute path to the binaries would be on the user writing the hooks in their nix configuration. |
|
Also, it's just a matter of preference but you might want to remove settings = with lib; mkOption {
type = types.submodule {
freeformType = tomlFormat.type;
options = {
templates = lib.mkOption {
type = with lib; types.attrsOf (types.submodule {
options = {
input_path = mkOption {
type = types.path;
example = "./style.css";
description = "Path to the template";
};
output_path = mkOption {
type = types.str;
example = ".config/style.css";
description = "Absolute path where the generated file will be written to";
};
post_hook = mkOption {
type = types.str;
example = "";
description = "Shell command to run after generating a template. {{placeholders}} are allowed";
};
};
});
default = osCfg.templates or {};
description = ''
Templates that have `{{placeholders}}` which will be replaced by the respective colors.
See <https://github.com/InioX/matugen/wiki/Configuration#example-of-all-the-color-keywords> for a list of colors.
'';
};
};
};
example = lib.literalExpression ''
settings = {
config.wallpaper = {
set = true;
command = "\${lib.getExe pkgs.swww}";
arguments = [
"img"
"--transition-type"
"center"
];
};
templates.gtk3 = {
input_path = ./gtk.css;
output_path = "\${config.xdg.configHome}/gtk-3.0/gtk.css";
};
};
'';
description = ''
Settings to write to the matugen configuration file
A manual for configuring matugen can be found at <https://github.com/InioX/matugen/wiki/Configuration>
'';
}And for the record, you could just make the type of both |
Co-authored-by: ys5g <136090707+ys5g@users.noreply.github.com>
Co-authored-by: ys5g <136090707+ys5g@users.noreply.github.com>
InioX
force-pushed
the
main
branch
2 times, most recently
from
09682fb to
4dbb91c
Compare
This PR addresses my issue #60. It is built to allow both a declarative and imperative nix config.
Draft Status
Currently the imperative part is completely implemented. To imitate functionality of the old home-manager module I'd like to request a feature on the main matugen binary. The option
matugen --prefix <path>, which should manipulate the out_paths for all targets would make this module significantly more simple and maintainable. I also think the prefix option would be useful in general.I plan on adding a wrapper script that automatically removes the symlinks made by home-manager once someone runs matugen. That way users can have, as mentioned before, both a declerative matugen setup, and still use the command normally. (Because otherwise you'd get a
IO error: File system is immutablewhen trying to write in the nix store). For convenience, and because there's barely a difference in implementing that I'll also allow users to hook into that script.Duplicate
#65 is a PR solving the same issue. I didn't realize there was already someone else trying to fix this and by the time I realized I was already 90% done. Sry abt that.
RFC
One thing I wanted to mention is that we should probably remove the osCfg. There's no point in that and it adds unnecessary complexity. No one configures themes system-wide.
Example Usage
Configuring the settings would look something like this.
You can add templates like this