feat(nixos): add hostname automatically

[yajo]

@moduon MT-9339

[phaer]

While this is useful for "pet servers" and those are the main focus of blueprint, I think it's still a good idea to try not being too opinionated here and allow "cattle" for e.g. ephemeral hosts as well. There you could deploy multiple hosts from a single nixosConfiguration, but networking.hostName and friends don't help there.

So I am skeptical whether this should be a default. I think it might be better kept downstream (e.g. in an opinionated collection of modules such as https://github.com/nix-community/srvos) or at least optional.

[yajo]

Sorry because I didn't explain the problem I'm fixing here.

There's no way to know on which machine you're running. Yes, under /hosts you give them a name. However, that name is not propagated anywhere. So if you have machine-specific logic, you can't just check what machine you're running and react to that.

So, the logic here is the equivalent to this, which is already there:

blueprint/lib/default.nix

Line 287 in a18c84c

home.username = lib.mkDefault username;

You don't really say the username explicitly in a module. You just create a folder and then blueprint automatically infers the username from the folder name and tells it to home-manager.

Also, packages get a pname argument automatically, based on the folder name.

In the same fashion, we shouldn't have to specify a machine hostname by hand on the system configuration. Instead, we should just create the /hosts/<machine name>/configuration.nix and NixOS should know by default what's the name of the machine.

Notice that I'm using lib.mkDefault, so if you have any other more specific configurations, those won't get overridden.

I don't think this belongs to srvos. This is something that should form part of the design of blueprint, as it is useful only to blueprint users (srvos doesn't expect any specific folder structure).

[phaer]

There's no way to know on which machine you're running. Yes, under /hosts you give them a name. However, that name is not propagated anywhere.

True, just opened #99 with a proposal to fix that. What do you think?

So, the logic here is the equivalent to this, which is already there:

Yes, I personally think that we should rather rethink and minimize the home-manager supporting code than taking it as an example for even more (IMO) overly-specific code.

I don't think this belongs to srvos.

The reference to srvos was meant as an example for a more opinionated collection of module options. From my point of view, blueprint should have strong opinions with regards to structure, to spare you the boilerplate, but less so with regards to content.

[yajo]

No matter what, I still think my original solution is the best. I cannot imagine a single reason why someone would expect that a nixos host defined in blueprint doesn't have a default hostname matching the folder name.

#99 looks good too, but I bet about 99.99% of users Will have to add a extra module to do what I proposed.

Nevertheless I pushed a different prototype here, só you can have yet another option. It can be a good solution for #97 too (the approach).

[phaer]

No matter what, I still think my original solution is the best.

Tbh, this makes me wonder whether it's still useful to discuss, if there's no chance to convince you "no matter what". I'll still try, even if just for people possibly reading along, and ideally to convince you that there's more to it than extrapolating personal use-cases and preferences.

I cannot imagine a single reason why someone would expect that a nixos host defined in blueprint doesn't have a default hostname matching the folder name.

I gave you one in my first reply: "you could deploy multiple hosts from a single nixosConfiguration, but networking.hostName and friends don't help there.".
There's also the image building use-case and probably others as well. The diversity of usage inside the community means it's very, very, if possible at all, to understand all use-cases as a single individual. That's why listening to each other in debates like these is so useful :)

#99 looks good too, but I bet about 99.99% of users Will have to add a extra module to do what I proposed.

What are you betting on? And how could you possibly know? It's not true for my personal use cases for example and at this point I am positive that I am more than 0.01% of the user base (i.e. that we have less than 10k users ;))

I also think it's a misunderstanding of what blueprint tries to be. The readme calls it "Standard folder structure for Nix projects" or

blueprint is an opinionated library that maps a standard folder structure to flake outputs. It makes common use cases easy both for the author and consumers

Note that it's about the folder structure, not the whole nixos configuration or so. (And i did agree that setting attributes for home-manager is probably sub-optimal).

Your current proposal would be the very first blueprint-specific nixos option. I'd prefer if we keep such to a downstream project which could of course depend on blueprint for the structure.

Nevertheless I pushed a different prototype here, só you can have yet another option. It can be a good solution for #97 too (the approach).

I don't yet understand how, but you are welcome to open a PR.

[phaer]

Closing this as #99 was merged, which solves some of the issue described and allows solving the rest downstream. Thanks for bringing this up @yajo !

[yajo]

Thank you very much! Sorry I wasn't saying #99 is a bad solution! Sometimes written communication sounds harsh but it wasn't my intention. I was just saying that the other solution seemed better to my and why. But I understand there are other use cases and that you prefer a different one.

Sorry for those invented statistics. And thanks for blueprint and all the work behind.

FWIW I migrated from snowflake lib because blueprint is less opinionated. Thanks!