I quite like the idea this is going for. On the other hand this is on a template repo for introducing "newbies" as it was put before here #14. So I feel the complexity of the changes somewhat out shines the actual benefit. But I would be willing to hear out the thoughts of others.

If anything, introducing the end-user to the module system smoothly just eases out the difficulty curve that they are bound to hit eventually. The "complexity" comes from the lack of proper introductions, which we can solve by ourselves.

I would have 1000 commits less on my system config if anyone told me I could use the module system inside my system

Regarding the complexity vs benefit trade-off: This depends on whether "introducing 'newbies'" should err on the side of "simpler" or on the side of "properly structured/ready for extending into my config over time".

I believe the latter is what we should aim for.
Starting with a template, only to later on discover you should probably redo half your config probably feels quite discouraging, especially for beginners.

On the other hand, starting with something simpler, that I, as a new user, can more fully grasp, may outweigh the benefits. Although I would argue, that this 'full understanding' better fits as part of a 'reference' documentation.

In short: For me, the benefits do outweigh the added complexity.

I agree, I think getting them started with modules earlier is better when opposed to the difficulty of rewriting from scratch

I agree that modules is a great start! I have some thoughts on the comments and the structure, but I don't want to flag it as ready for review until you're ready.

Barring the existence of some form of "template setup wizard", similar to eg. npm create svelte@latest's flow (maybe that's something we should look into!), I think the current state of affairs is as good as it's going to get. I'm not aware of any template prefilling functionality in nix flake init, and I think the complexity of adding an additional module system that exists only within this template, and isn't relevant outside of a from-scratch setup, would end up being potentially confusing to new users.

I still think that this has merit. I agree that only having one module is a little limiting, but we could definitely expand. For example, combining all the stuff from home-manager and nix home.stateVersion and system.stateVersion through one module (and add more stuff, just what's on my mind), and maybe adding different system templates down the line (a customized GNOME, KDE, Hyprland, etc.) through these modules. For a new user, everything is equally confusing to them, so just changing what we tell them to change and leaving it alone until they understand what it does better is fine, since that's how they're going to interact with the entire config anyway.

You'll notice that this PR is still a draft, and that is for good reason. I do not think the number of module options we provide by default matters (unless we want to play with different types) but there is bound to be a point at which it will appear complicated.

I'll try to think of a few more module options that makes sense. As @jakehamilton hostname may be redundant, but I currently cannot think of anything better.

If we want to have modules providing convenience wrappers for things like that, why not distribute them as part of the rest of the module set? That way everyone can use them, not just template users.

I believe the idea here is to show new users how they can create their own module(s)/how modules work/the benefit of custom modules, rather than fulfilling a specific (technical) need.

Of course, some user developped modules will provide generally useful abstractions. I do believe it's important to develop some means to ensure those are upstreamed, but this is out of scope for this PR, imho.

If we want to have modules providing convenience wrappers for things like that, why not distribute them as part of the rest of the module set? That way everyone can use them, not just template users.

The goal of the PR is to replace a fragile and non-futureproof system (cramping variables in a let in block) with an instructive enough module system - not to create an entire module system based on convenience.

I believe the idea here is to show new users how they can create their own module(s)/how modules work/the benefit of custom modules, rather than fulfilling a specific (technical) need.

That is correct.

I think that makes sense. I'd consider also creating a template without this module system, as (bit of a gut feeling, but) I feel many power users would end up just deleting this module from the template anyway and structuring things themselves (one might argue that a power user probably doesn't need a template, but templates are still convenient to have). Definitely some value in introducing new users to the module system though, I think that's fair.

#25 fixes the first point in the OP.

I'll rebase.

i don't think a single option in a system template is a great way to introduce users to module creation. i would much rather see a full template for this that won't be overshadowed by a larger purpose (configuring an entire operating system) and can go more in depth with multiple examples of options with real world applications. i would also this isn't much better than specialArgs, as it continues to introduce non-standard aspects into a configuration to fit what is really a contrived example (see #3 for a more in depth explanation)

The goal of the PR is to replace a fragile and non-futureproof system (cramping variables in a let in block)

im not sure what variables are being referred to here. there's only in system, which could just as easily be moved to the nixosSystem arguments directly

with an instructive enough module system

see above. modules are an extremely loaded topic and i don't feel like this is a very good introduction. it's very much deserving of it's own template imo

i don't think a single option in a system template is a great way to introduce users to module creation.

I disagree. It answers the question of "where do I start?"

im not sure what variables are being referred to here. there's only in system

not referring to any specific variable, but it's making a bad example. at one point in the future there's going to be "oh, so I can put my username in here and it'll just work!" moment because we haven't shown the alternative

see above. modules are an extremely loaded topic and i don't feel like this is a very good introduction. it's very much deserving of it's own template imo

sure, we can make a standalone template that shows the module system - but at that point why aren't we actually documenting all this? if there is going to be a template with the module system and one without, one of those are bound to be redundant.

I'm closing this. Looks like I don't have the time to approach it from a different angle. However, I'll return to this in the future; probably as an example in the documentation.