I have begun a new project recently, with the goal of creating a generic repository that can serve as a good basis for nixos configurations. Since flakes are coming down the pipe, the whole project is designed using them. This makes it trivial to pin nixpkgs to any version or even declare multiple versions of nixpkgs as inputs (not to mention any other flakes). In addition, any package definitions, modules, overlays, and even whole system configurations can be trivially shared between flakes.
The README.md should be able to get you up and running super quick. There are some useful links to learn more about flakes there as well. One of the design goals is to allow for incremental adoption, so you really can just drop in your current configuration right away, and slowly port it to match the modular structure the project defines. In addition the shell.nix pulls in an experimental build of nix with flakes support so there is virtually no setup to try it out!
I think it’d be a good idea to have a standardized repository structure for NixOS. Using flakes future proofs the effort and makes things that were once difficult or tedious much easier.
In addition, reusable configuration snippets can live in this template, providing a good starting point for newbies to get up and running with NixOS with a fully functional system in mere moments. Check out the profiles directory for some examples.
Nothing is set in stone (including the name), so if you have any good suggestions please let me hear them. Also, depending on the reception, I am thinking about opening an rfc to potentially include this flake as part of the NixOS organization on GitHub and possibly add it to the flake registry for easy access.
I’ve also written a brief list of the advantages in a separate thread.
Thank you a lot for doing this! I am dreaming of a project which is a bit like Manjaro Linux is to Archlinux, an ISO you can install to have a cleverly preconfigured and very nice looking NixOS. But for that to happen a reasonable, easily customizable skeletton structure is necessary. I thought about trying to building such a skeletton as you now did last August but I thought I rather wait for Flakes
Since I‘m always starting new projects I never finish (and given my rather small nix knowledge) I‘m really glad you started this project and I hope this can become an RFC!
Not right now, build-vm hasn’t be implemented for flakes. If you try it with nixos-rebuild for example it will tell you as much.
Nixos-rebuild does actually work with flakes, but there was a bug in the current flake branch that prevented it from deploying, which I actually fixed in my fork of nixpkgs, but in case anyone wanted to use their own fork, I created the rebuild command as a backup.
Once flakes get merged this should work. For now you could build an iso using rebuild iso and manually deploy it via virtualbox or kvm though. You could also run rebuild test to deploy to your current hardware but revert to your previous configuration on reboot.
If I understand correctly, with nixflk hardware-configuration.nix and configuration.nix are the same file. Isn’t it a good idea to keep hardware-configuration.nix separate so we can run nixos-generate-config from time to time (or after a release) to get the new recommended defaults?
That’s already the case! But if it will be even easier, that good. The hardest part for me (which wasn’t more difficult than copy/pasting command from the manual) was mounting the partitions (boot, nixos, swap). After that, I added some packages to my config, ran the install command, rebooted, and it all simply worked!
It’s already quite easy (f.e. compared to Arch Linux, where everything about the hardware has to be manually configured).
If this makes things even easier, I’ll be even more impressed!
Do you mind posting an example of what a basic config might look like, for example assuming a user wants to boot into a Gnome desktop with Chrome, Firefox, and VS Code available? EDIT: I looked at the examples in profiles, and to be honest as a newb I don’t notice much different. I imagine this will be more helpful for those who are making the package expressions, rather than someone consuming them and getting started with supported/existing features/packages?
What I mean by getting started is that they can actually have a fully configured system, rather than just a bare bones starting point. Of course the more profiles that get contributed the more true this will be. Since we’re just starting out, there’s only a few profiles so far.
I wouldn’t say it’s only useful for developers, maybe at this exact moment: yes. But soon, flakes will be the default entry point for users as well. This is in preperation for when that time comes, so that those users can have a strong foundation of expressions to choose from. The whole point of this project for me, was for users to be able to deploy advanced configurations within moments of learning of NixOS. That’s the end game at least.
Of course it all depends on whether the community finds this useful or not. If so, I’ll draft an rfc, but at least not until the rfc for flakes has been officially merged. Until then, consider it experimental.
As for profiles, the fact that you notice no difference is actually the point. They are just NixOS modules. I’m just giving them a name to distinguish them from modules that declare new options, like those in nixpkgs, and also from hosts, which are highly machine specific.
Profiles don’t have different syntax, rather a different semantic context. The point is to be general enough for regular use by a user who doesn’t want to do any, or very little configuration themselves.
Not exactly. If you actually look at the configuration.nix generated by nixos-generate-config, it really doesn’t do much beyond set the boot loader and describe some commented out options to choose from. I micked this behavior in ./hosts/NixOS.nix.
You can absolutely do that if you want though. This is why I kept the structure of the repo to a bare minimum. You can keep your hardware-configuration in ./local instead and import it from the host. The point of hosts though, is so you can save configurations for any number of machines, not just one. So for me saving all the hardware specific bits in that machine allows me to change between deployments seemlessly.
Yes just check out the users section of the README.md. For convenience, I have flakified home-manager and included it by default. It can technically be used from anywhere but for the sake of modularity, it is recommend that you only use it from the users directory.
As stated in the readme, users are just a special case of profiles and should be structured similarly. Check out my nrd branch to see an example. I use home manager in my user declaration as well.
One thing that just came to my mind is that if you want to create an RFC for this at some point (which I really hope!), we might also think about the idea of adding home-manager to the organization. Especially since you have „out-of-the-box“ support for it and it also seems to me that it is the absolutely recommended way of home management for a long time now.
When I first installed NixOS around 2 years ago I thought that it will probably be merged into Nixpkgs because of the very high usage of it. But I don‘t know if this is even possible and if @rycee would be interested in something like that.
Hey feel free to message the author, or even draft an rfc. Can’t hurt. For what its worth, I agree. home-manager or something like it should be a standard part of NixOS and is a glaring ommision. Systemd-homed is another option, though I’m not entirely a fan of the massive reliance on systemd, it might pass better with the community since we are already depedant on it upstream.
If a standard solution does present itself, I’ll include it in nixflk, but home-manager by default is nice enough for now. I haven’t even though of what I’d write in an rfc. Haven’t gotten enough feedback yet. We’ll cross that bridge if we come to it.
