stylix: restrict access to config while using mkTarget

[0xda157]

allows for accessing config once config has been removed from module args (if that ends up happening). Also allows for removal of the review burden of ensuring config.stylix or config.stylix.lib.colors isn't accessed when using config.

cc @trueNAHO @MattSturgeon @Flameopathic

Things done

• Tested locally
• Tested in testbed
• Commit message follows commit convention
• Fits style guide
• Respects license of any existing code used

Notify maintainers

[trueNAHO]

allows for accessing config once config has been removed from module args (if that ends up happening). Also allows for removal of the review burden of ensuring config.stylix or config.stylix.lib.colors isn't accessed when using config.

IIUC, this is for the following additional safety:

-{ config, mkTarget, ... }:
+{ mkTarget, ... }:
 mkTarget {
   name = /* ... */;
   humanName = /* ... */;
- configElements = ({ colors }: { /* ... */ });
+ configElements = ({ config, colors }: { /* ... */ });
 }

[MattSturgeon]

IMO this feels like something that should be done in the file's top-level args (which are currently the module args), rather than configElement args.

Only being able to access config from within a configElement feels cumbersome; you may wish to also access it in option defaults, in shared/common let binding, etc.

But I don't see any issue with the implementation, if you want to stick with this approach for now.

[Flameopathic]

IMO this feels like something that should be done in the file's top-level args (which are currently the module args), rather than configElement args.

Only being able to access config from within a configElement feels cumbersome; you may wish to also access it in option defaults, in shared/common let binding, etc.

Agreed. Though I can somewhat see the draw of wanting to eliminate the top-level args, I think that the visual improvement is very little in comparison to the increased difficulty for new contributors. Its abstractions are great for the future and people who understand it well, but the more mkTarget separates targets from the module system, the more difficult things will be to learn, understand, and debug.

[0xda157]

IMO this feels like something that should be done in the file's top-level args (which are currently the module args), rather than configElement args.

Only being able to access config from within a configElement feels cumbersome; you may wish to also access it in option defaults, in shared/common let binding, etc.

there are 3 options here

1. access config through top-level args. I don't like this because we can get everything except colors, fonts, etc through top-level args, so below still applies.

Only being able to access config from within a configElement feels cumbersome; you may wish to also access it in option defaults, in shared/common let binding, etc.

2. access config, colors, fonts, etc through top-level args. This breaks the mkIf != null thing.
3. don't access config through top-level args

[Flameopathic]

we can't get everything except colors, fonts, etc through top-level args, so below still applies.

What do you mean by this?

[MattSturgeon]

I don't like this because we can't get everything except colors, fonts, etc through top-level args, so below still applies

I don't think that's necessarily true. With some refactoring, mkTarget could apply top-level args to its input argument using the fnOrAttrs pattern.

This would work the same way as (e.g.) nixpkgs override functions that accept either attrs or a function. This is also what the module system checks internally when importing modules, since they are also fnOrAttrs values.

---

With the current design, usage would be a bit ugly, but this would improve once modules are no longer modules and are instead implicitly "args for mkTarget".

{ mkTarget, ... }:
mkTarget (
  { config, options, pkgs ... }:
  {
    name = "foo";
    humanName = "bar";
  }
)

[MattSturgeon]

LGTM, but the commit/title should change to reflect that this isn't adding the ability to access config. Rather it is adding restrictions to the config that was already accessible.

Something like stylix: restrict access to config in mkTarget?

[trueNAHO]

Code LGTM. Could you rebase to resolve the merge conflicts and double check that no config module accesses have been missed elsewhere in the tree?

[trueNAHO]

LGTM.

[0xda157]

either need to manual merge or have @danth approve for the auto merge to work

[stylix-automation]

Successfully created backport PR for release-25.05:

• [release-25.05] stylix: restrict access to config while using mkTarget #1592