-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract overrides option to Home Manager #128
Comments
Hi @brckd, Thanks for reaching out.
I am not familiar with Stylix, do you have a minimal sample config that I can repro? Something I can plugin in a https://github.com/gmodena/nix-flatpak/tree/main/testing-base VM would be great. It might be a problem on how modules are imported rather than imports themselves. Are you passing modules to HomeManager via In danth/stylix#465 (comment) you mention:
Would #82 help you?
In principle, I don't oppose re-licensing parts of nix-flatpak and working with upstream for integrations. However, I'm not sure it's necessary; I'd prefer the modules to be orthogonal if possible. Most importantly, I want the I need to understand both the problem and proposed solution before making a commitment. If the issue is how |
Thanks for your reply on this issue. Sorry for not telling you this earlier, but I had found a quick solution in the meantime as described in danth/stylix#693 (comment). I will still try to answer your questions as best as possible to hopefully find a better long term solution.
I'm also unfamiliar with the testing base VM, but here is a simplified structure of Stylix if it was to use the nix-flatpak module. Note that the project also uses flake-utils and more nested imports, but this version should cover the most essential parts. # flake.nix
{
inputs = {
nix-flatpak.url = "github:gmodena/nix-flatpak";
home-manager.url = "github:nix-community/home-manager";
};
outputs = { home-manager, ... }@inputs: {
homeConfigurations.stylix = home-manager.lib.homeManagerConfiguration {
imports = [
(import ./templates.nix inputs)
./gtk.nix
];
};
};
} # templates.nix
inputs:
{
config.lib.stylix.templates = {
inherit (inputs) nix-flatpak;
};
} # gtk.nix
{ config, ... }:
{
imports = [ config.lib.stylix.templates.nix-flatpak.homeManagerModules.nix-flatpak ];
config.services.flatpak.overrides.global = {
Context.filesystems = ["${config.home.homeDirectory}/.themes/${config.gtk.theme.name}:ro"];
Environment.GTK_THEME = config.gtk.theme.name;
};
}
As far as I'm aware, Stylix does not.
If I understand correctly and #82 suggests to create a nix-flatpak option to add additional override files to the final override file, it would likely help indeed. It would then be up to the user to add Stylix's generated file to that option, like
Since I have found a working solution, I'd say it's not necessary. Thanks for offering the option though.
Yes, #82 seems like a much easier solution to this problem and would love to see it be implemented instead! |
As described in #25, importing nix-flatpak in other third-party modules that import home-manager creates problems. This also applies for Stylix with its pending support for theming Flatpak apps as hinted in danth/stylix#465 (comment). Therefore Stylix will currently use an incompatible in-house solution as described in danth/stylix#693 (comment).
One solution to this problem is to extract the user override options into Home Manger. This would eliminate the need to import nix-flatpak into Stylix in the first place and makes modules using the option compatible. The code cannot be extracted directly, because this project's and Home Manager's license and copyright are not compatible. A new solution would need to be written for Home Manager, but this would fragment the code for home and NixOS overrides.
Please let me know whether this is a desirable solution that can be adapted by this project.
The text was updated successfully, but these errors were encountered: