Skip to content
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

Open
brckd opened this issue Dec 22, 2024 · 2 comments
Open

Extract overrides option to Home Manager #128

brckd opened this issue Dec 22, 2024 · 2 comments

Comments

@brckd
Copy link

brckd commented Dec 22, 2024

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.

@gmodena
Copy link
Owner

gmodena commented Dec 28, 2024

Hi @brckd,

Thanks for reaching out.

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).

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 viaextraSpecialArgs?

In danth/stylix#465 (comment) you mention:

Instead of writing to its services.flatpak.overrides.global option, we can directly write the configuration as TOML to xdg.dataFile."flatpak/overrides/global" for HM or /var/lib/flatpak/overrides/global for NixOS. But this might conflict with nix-flatpak when attempting to write options there as well.

Would #82 help you?

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.

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 nix-flatpak API to remain consistent across NixOS and Home Manager modules.

I need to understand both the problem and proposed solution before making a commitment.

If the issue is how nix-flaptak manages overrides (like #82), I'd rather resolve that in-tree.

@brckd
Copy link
Author

brckd commented Dec 28, 2024

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 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.

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;
  };
}

It might be a problem on how modules are imported rather than imports themselves. Are you passing modules to HomeManager viaextraSpecialArgs?

As far as I'm aware, Stylix does not.

Would #82 help you?

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 services.flatpak.overrideFiles = [ xdg.dataFile."flatpak/overrides/global" ];.

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 nix-flatpak API to remain consistent across NixOS and Home Manager modules.

Since I have found a working solution, I'd say it's not necessary. Thanks for offering the option though.

I need to understand both the problem and proposed solution before making a commitment.

If the issue is how nix-flaptak manages overrides (like #82), I'd rather resolve that in-tree.

Yes, #82 seems like a much easier solution to this problem and would love to see it be implemented instead!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants