firefox: add gnome-theme testbed

[brckd]

Adds a separate testbed for Firefox with firefoxGnomeTheme.enable = true as per
#702 (comment).

[brckd]

I just tested it and it works, but it has some weird artifacts.
Screencast From 2025-02-18 18-36-18.webm

This only happens in the testbed, so I wouldn't be too concerned about this.

[trueNAHO]

Considering hyphens are not allowed in testbed names, should we rename the testbed to gnome_theme? This naming convention scales better, if we add longer testbed names in the future. @danth, what do you think?

[danth]

We should find a better solution for naming testbeds so that hyphens are allowed, as hyphens are pretty standard for this sort of thing in other Nix projects. Potentially we could move to a nested structure, although that may be incompatible with certain nix commands.

For the purposes of this PR I would just leave it as gnometheme.

[brckd]

Some module names also include hyphens, so I'd consider a different separator like . when running a testbed. So you'd run nix run .#testbed.module.testbed.polarity. We could still replace that with - in the derivation name like testbed-module-testbed-polarity because derivation names usually don't carry semantic meaning.

[brckd]

I don't really get why this testbed is failing, because it's pretty much identical to the other firefox testbed.

[danth]

The nested structure I mentioned would work with .s as you described - only issue is things like nix flake show might not list the packages correctly

[danth]

I don't really get why this testbed is failing, because it's pretty much identical to the other firefox testbed.

This will be due to the use of builtins.readFile in the GNOME theme part of the module. We could try replacing it with an @import if that works

[brckd]

I don't really get why this testbed is failing, because it's pretty much identical to the other firefox testbed.

This will be due to the use of builtins.readFile in the GNOME theme part of the module. We could try replacing it with an @import if that works

Yea, that should work. Thanks for pointing it out! So I assume that builtins.readFile isn't declarative enough for derivations, but builtins.import is.

[brckd]

Ok, it seems like import is not allowed either.

[brckd]

According to https://nix.dev/manual/nix/2.25/language/import-from-derivation, this happens when a derivation depends on another derivation in any way. It's actually just a performance measure, so I wonder if we can somehow turn it off. The allow-import-from-derivation is enabled by default, so perhaps Determinate Nix turned it off.

[trueNAHO]

Some module names also include hyphens

True.

so I'd consider a different separator like . when running a testbed. So you'd run nix run .#testbed.module.testbed.polarity. We could still replace that with - in the derivation name like testbed-module-testbed-polarity because derivation names usually don't carry semantic meaning.

The . separator seems very convenient.

The nested structure I mentioned would work with .s as you described - only issue is things like nix flake show might not list the packages correctly

In that case, derivation names need to be quoted:

nix run '.#"testbed.module-name.dark"'

Since this is fairly annoying to type, we could chose another separator, like ::

nix run .#testbed:module-name:dark

According to https://nix.dev/manual/nix/2.25/language/import-from-derivation, this happens when a derivation depends on another derivation in any way. It's actually just a performance measure, so I wonder if we can somehow turn it off. The allow-import-from-derivation is enabled by default, so perhaps Determinate Nix turned it off.

IFD is disabled inside the CI since commit d8289c3 ("ci: disable IFD (#855)").

[danth]

What about this?

 userChrome =
  let template = config.lib.stylix.colors {
    template = ./userChrome.mustache;
    extension = "css";
  };
  in ''
    @import "${template}";
  '';

IFD is intentionally disabled in the CI as some systems, such as Hydra, don't allow it by default, so we try to avoid IFD wherever possible so that user's configurations are compatible with that (and also the performance improvements as you mentioned).

[trueNAHO]

Some module names also include hyphens

True.

so I'd consider a different separator like . when running a testbed. So you'd run nix run .#testbed.module.testbed.polarity. We could still replace that with - in the derivation name like testbed-module-testbed-polarity because derivation names usually don't carry semantic meaning.

The . separator seems very convenient.

The nested structure I mentioned would work with .s as you described - only issue is things like nix flake show might not list the packages correctly

In that case, derivation names need to be quoted:

nix run '.#"testbed.module-name.dark"'

Since this is fairly annoying to type, we could chose another separator, like ::

nix run .#testbed:module-name:dark

I implemented this in #887.

[danth]

In that case, derivation names need to be quoted

I meant that we use attribute sets inside attribute sets, like

{
  gnome = {
    default = {
      light = «derivation»;
      dark = «derivation»;
    };
  };
}

This would not require quoting.

However I can confirm this is not supported by nix flake show and results in an error, unless we move it to legacyPackages.

[brckd]

In my opinion legacyPackages would indeed be the solution here. There is nothing legacy about legacyPackages and it's simply intended for nested packages like this one. I think this is also a common pattern.

[trueNAHO]

In my opinion legacyPackages would indeed be the solution here. There is nothing legacy about legacyPackages and it's simply intended for nested packages like this one. I think this is also a common pattern.

Can legacyPackages be added to the checks output? If not, then we have to flatten the legacyPackages structure when adding it to checks, which negates the problem legacyPackages is trying to solve. Instead, #887 solves the flat structure itself.