treewide: propagate inputs and remove templates

[Flameopathic]

fixes #238

[Flameopathic]

inputs does not seem to be properly propagating; it's likely that i'm somehow setting it wrong.

[danth]

I'm fairly sure this will cause a conflict if the user already has their own inputs in _module.args (or specialArgs). It's pretty common for people to do this.

I suggested an alternative implementation in #873 (comment): essentially, give each module a stylix.targets.*.template option and set these options from flake.nix, as we're now doing for some of the other flake inputs:

stylix/flake.nix

Lines 221 to 225 in c74352a

	stylix = {
	paletteGenerator = self.packages.${pkgs.system}.palette-generator;
	base16 = base16.lib args;
	homeManagerIntegration.module = self.homeManagerModules.stylix;
	};

This still requires listing each template, however it's cleaner than passing inputs through as a function argument.

[Flameopathic]

I'm fairly sure this will cause a conflict if the user already has their own inputs in _module.args (or specialArgs).

crap, you're probably right

I suggested an alternative implementation in #873 (comment): essentially, give each module a stylix.targets.*.template option and set these options from flake.nix, as we're now doing for some of the other flake inputs: [...]

that would work, though it seems like it wouldn't scale as well as giving the modules access to inputs, and i still have hope for there being a clean way of doing it.

if you have a strong enough preference, i'll go straight for the stylix.targets.*.template option; otherwise i think giving all modules inputs would result in the best developer experience

[danth]

Alternatively, we could just use a different name under _module.args.

Or have just one readonly option containing all the inputs.

I was also thinking with the stylix.targets.*.template options that it might be possible to make these public, to give users an easier way to override the template if they want to. That does raise backwards compatibility issues if we want to replace the template with inline options in the future, though.

[Flameopathic]

Alternatively, we could just use a different name under _module.args.

Or have just one readonly option containing all the inputs.

of these two, the latter would probably be the most intuitive to contributors. i suppose that's what i'm leaning toward ATP

I was also thinking with the stylix.targets.*.template options that it might be possible to make these public, to give users an easier way to override the template if they want to. That does raise backwards compatibility issues if we want to replace the template with inline options in the future, though.

that could be nice, but would users be able to do anything other than override definitions of single colors? i think something like that would be better handled by #685

[trueNAHO]

Alternatively, we could just use a different name under _module.args.
Or have just one readonly option containing all the inputs.

of these two, the latter would probably be the most intuitive to contributors.

Agreed.

I was also thinking with the stylix.targets.*.template options that it might be possible to make these public, to give users an easier way to override the template if they want to. That does raise backwards compatibility issues if we want to replace the template with inline options in the future, though.

that could be nice, but would users be able to do anything other than override definitions of single colors? i think something like that would be better handled by #685

Agreed.

[Flameopathic]

if making a read-only option, would stylix.inputs or lib.stylix.inputs be better? what exactly should go in lib vs not?

also how are options being put under lib? i can't seem to find any option definitions starting with lib.stylix, though i could be missing something because there are many, many usages of lib.

[Flameopathic]

current solution makes read-ony option stylix.inputs and populates it with all inputs from the Stylix flake

[danth]

lib is a special option which allows anything to be stored inside it without any type checking.

We're moving away from this to use defined read-only options instead.

[danth]

We should mark the option as internal = true since it's not meant to be used externally. This hides it from the public documentation.