auxolotl/templates
20
2
Fork 4
Code Issues 3 Pull requests 2 Actions Packages Projects Releases Wiki Activity

treewide: replace system variables with a local module system #22

Closed
NotAShelf wants to merge 2 commits from main into main
pull from: main
merge into: auxolotl:main
Conversation 17 Commits 2 Files changed 3 +28 -4
NotAShelf commented 2024-05-04 10:10:15 +00:00 (Migrated from github.com)
Copy link

Currently just a draft. I'd like to hear a bit from others to see if this is a change worth pursuing, or if it gets deemed too complicated.

  • Formats darwin template with nixfmt
  • Replaces the local variables in flake.nix with a module system the user can expand
  • Removes system that was passed to nixosSystem, which is actually not necessary. I will replace this with nixpkgs.hostPlatform in a future commit, but that is going to be in the generated hardware-configuration.nix so it may not be necessary.
Currently just a draft. I'd like to hear a bit from others to see if this is a change worth pursuing, or if it gets deemed too complicated. - Formats darwin template with nixfmt - Replaces the local variables in flake.nix with a module system the user can expand - Removes `system` that was passed to nixosSystem, which is [actually not necessary](https://github.com/NixOS/nixpkgs/blob/ba10489eae3b2b2f665947b516e7043594a235c8/nixos/lib/eval-config.nix#L12-L15). I will replace this with `nixpkgs.hostPlatform` in a future commit, but that is going to be in the generated hardware-configuration.nix so it may not be necessary.
👍 1 🚀 1
isabelroses commented 2024-05-04 13:31:05 +00:00 (Migrated from github.com)
Copy link

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 https://github.com/auxolotl/templates/pull/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.

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 https://github.com/auxolotl/templates/pull/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.
NotAShelf commented 2024-05-04 14:02:17 +00:00 (Migrated from github.com)
Copy link

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

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
👍 4
liketechnik commented 2024-05-04 19:26:50 +00:00 (Migrated from github.com)
Copy link

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.

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.
👍 2
TheCodedProf commented 2024-05-04 19:29:42 +00:00 (Migrated from github.com)
Copy link

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

I agree, I think getting them started with modules earlier is better when opposed to the difficulty of rewriting from scratch
❤️ 3
imadnyc commented 2024-05-05 01:17:22 +00:00 (Migrated from github.com)
Copy link

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.

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.
jakehamilton (Migrated from github.com) reviewed 2024-05-05 02:45:08 +00:00
system/options.nix
@ -0,0 +9,4 @@
# will become available under `config.aux` within your configuration. Thus making it
# possible to reference arbitrary internal variables if they have been set here
options.aux = {
hostname = mkOption {
jakehamilton (Migrated from github.com) commented 2024-05-05 02:45:08 +00:00
Copy link

We should be extremely cautious about adding options. It doesn't seem like this one is used for anything other than mapping directly to networking.hostname. Maybe we can just use the available option and have an explicit "example" option if the intention is to show how to create options.

We should be extremely cautious about adding options. It doesn't seem like this one is used for anything other than mapping directly to networking.hostname. Maybe we can just use the available option and have an explicit "example" option if the intention is to show how to create options.
srxl commented 2024-05-05 03:25:18 +00:00
Member
Copy link

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.

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.
NotAShelf (Migrated from github.com) reviewed 2024-05-05 04:04:56 +00:00
system/options.nix
@ -0,0 +9,4 @@
# will become available under `config.aux` within your configuration. Thus making it
# possible to reference arbitrary internal variables if they have been set here
options.aux = {
hostname = mkOption {
NotAShelf (Migrated from github.com) commented 2024-05-05 04:04:56 +00:00
Copy link

This serves firstly to introduce the user to the module system, and secondly to avoid the user accidentally putting the hostname in specialArgs. Not exactly necessary, but not quite sure what else to put in a starter module system.

This serves firstly to introduce the user to the module system, and secondly to avoid the user accidentally putting the hostname in specialArgs. Not exactly necessary, but not quite sure what else to put in a starter module system.
imadnyc commented 2024-05-05 05:22:16 +00:00 (Migrated from github.com)
Copy link

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.

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.
NotAShelf commented 2024-05-05 06:24:20 +00:00 (Migrated from github.com)
Copy link

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.

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.
❤️ 2
srxl commented 2024-05-05 08:02:32 +00:00
Member
Copy link

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.

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.
👍 1
liketechnik commented 2024-05-05 12:56:14 +00:00 (Migrated from github.com)
Copy link

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.

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.
NotAShelf commented 2024-05-05 13:14:08 +00:00 (Migrated from github.com)
Copy link

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.

> 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.
👍 4
srxl commented 2024-05-05 13:21:37 +00:00
Member
Copy link

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.

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.
AxelSilverdew commented 2024-05-05 14:14:08 +00:00 (Migrated from github.com)
Copy link

https://github.com/auxolotl/templates/pull/25 fixes the first point in the OP.

https://github.com/auxolotl/templates/pull/25 fixes the first point in the OP.
❤️ 1
NotAShelf commented 2024-05-05 14:20:40 +00:00 (Migrated from github.com)
Copy link

I'll rebase.

I'll rebase.
👍 1
getchoo commented 2024-05-07 06:49:23 +00:00 (Migrated from github.com)
Copy link

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 https://github.com/auxolotl/templates/pull/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 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 https://github.com/auxolotl/templates/pull/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
NotAShelf commented 2024-05-07 10:51:52 +00:00 (Migrated from github.com)
Copy link

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 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.
NotAShelf commented 2024-05-07 10:55:44 +00:00 (Migrated from github.com)
Copy link

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.

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.
❤️ 1

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

  
Compat
Breaking
Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Compat
Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: auxolotl/templates#22
No description provided.
Delete branch "main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?