treewide: add overlays option

[brckd]

Adds the stylix.overlays.enable option which can be disabled to remove all overlays. This is to handle scenarios where overlays cannot be set, because the configuration doesn't handle its own nixpkgs instance. Fixes #865.

[awwpotato]

lgtm

[brckd]

Haven't really tested it so far FYI.

[awwpotato]

tested it with my config and it's passing nix flake check

[brckd]

I used lib.mkIf to conditionally add overlays. Wouldn't #865 (comment) be relevant?

It seems that it's not.

[trueNAHO]

This PR does not resolve the root problem, and instead works around it by simply disabling affected code. With commit nix-community/home-manager@662fa98 merged, we can take our time to properly resolve this.

@danth, any ideas?

[brckd]

AFAIK this is the proper solution, because overlays cannot be set from within home manager when useGlobalPkgs = true. I read that it was never really possible, but there was no warning that recognized it before. So by design there is no way around it. We could add a warning when implicitly setting overlays.enable = false in the HM integration though.

[trueNAHO]

AFAIK this is the proper solution, because overlays cannot be set from within home manager when useGlobalPkgs = true. I read that it was never really possible, but there was no warning that recognized it before. So by design there is no way around it.

Any way we can use useGlobalPkgs as default?

[brckd]

Yes, it's used by the HM integration to override the default value.

stylix/stylix/home-manager-integration.nix

Lines 228 to 230 in e3fe2c6

	(lib.mkIf config.home-manager.useGlobalPkgs {
	home-manager.sharedModules = [ disableOverlaysModule ];
	})

stylix/stylix/home-manager-integration.nix

Lines 10 to 12 in e3fe2c6

	disableOverlaysModule = {
	config.stylix.overlays.enable = false;
	};

We could think about using lib.mkDefault though.

[trueNAHO]

We could think about using lib.mkDefault though.

We generally avoid lib.mkDefault: #388.

[trueNAHO]

Yes, it's used by the HM integration to override the default value.

stylix/stylix/home-manager-integration.nix

Lines 228 to 230 in e3fe2c6

	(lib.mkIf config.home-manager.useGlobalPkgs {
	home-manager.sharedModules = [ disableOverlaysModule ];
	})

stylix/stylix/home-manager-integration.nix

Lines 10 to 12 in e3fe2c6

	disableOverlaysModule = {
	config.stylix.overlays.enable = false;
	};

Should we do that or leave it as-is?

[brckd]

Are you asking me? I added it because it covers the case where one would be required to set this anyways.

[donovanglover]

Tested and works. No more home-manager warnings with useGlobalPkgs

[danth]

This PR does not resolve the root problem, and instead works around it by simply disabling affected code. With commit nix-community/home-manager@662fa98 merged, we can take our time to properly resolve this.

@danth, any ideas?

My thoughts would be to treat nixpkgs overlays as a separate platform from NixOS / Home Manager / Darwin, and import it automatically where possible, similar to how we integrate Home Manager within NixOS.

The overall nixpkgs platform would be a function stylix config → nixpkgs overlay and each module would have the option to include a nixpkgs.nix which is also a function with this signature.

For example, the GNOME module's nixpkgs.nix could look like:

stylixConfig: self: super:

let theme = theme = self.callPackage ./theme.nix {
  inherit (stylixConfig) colors templates;
};

in {
  gnome-shell = super.gnome-shell.overrideAttrs (oldAttrs: {
    # Themes are usually applied via an extension, but extensions are
    # not available on the login screen. The only way to change the
    # theme there is by replacing the default.
    postFixup =
      (oldAttrs.postFixup or "")
      + ''
        cp ${theme}/share/gnome-shell/gnome-shell-theme.gresource \
          $out/share/gnome-shell/gnome-shell-theme.gresource
      '';
    patches = (oldAttrs.patches or [ ]) ++ [
      ./shell_remove_dark_mode.patch
    ];
  });
}

To validate that the format of the stylixConfig parameter is correct, we could use lib.types.submodule and manually call its check function: I was already planning to create such a submodule type anyway to facilitate nesting the global options under stylix.theme and having a different stylix.targets.*.theme per target.

[brckd]

My thoughts would be to treat nixpkgs overlays as a separate platform from NixOS / Home Manager / Darwin, and import it automatically where possible, similar to how we integrate Home Manager within NixOS.

Good idea, I have also seen other flake systems separating overrides into separate modules. I imagine they could also be a separate output like stylix.nixosModules.overrides.

The overall nixpkgs platform would be a function stylix config → nixpkgs overlay and each module would have the option to include a nixpkgs.nix which is also a function with this signature.

Why not use the usual module args like { config, lib, ... } instead of stylixConfig?

[danth]

I imagine they could also be a separate output like stylix.nixosModules.overrides.

I believe «flake».overlays.default would be the correct output for this. However, that doesn't provide a way to pass in the stylixConfig without breaking the expected format. So, we could use «flake».lib.«some function name» instead and allow the user to pass their config as a function argument, and then the function returns a valid overlay.

Why not use the usual module args like { config, lib, ... } instead of stylixConfig?

Unlike the existing platforms, nixpkgs doesn't use a module system, so this attribute set doesn't exist naturally.

We could construct it, but config would only contain config.stylix and nothing else, so it can be simplified to just stylixConfig. This could be renamed to just config, but that might cause confusion. lib can already be accessed as self.lib and/or super.lib.

I suppose we could still format the arguments as { stylixConfig, self, super } so that it's possible to use ... for any unused ones.