I’m tinkering with NixOS in a VM with an eye to possibly installing it bare metal on my laptop.
I followed the minimal install of NixOS and then the docs for installing desktop environments. (It’s very cool how easy it is to switch between them, and have confidence there’s no lingering files from the previous selection.)
I did find that the desktop environments were pretty lean. The plasma one doesn’t even include a browser, for example.
Are there high level “meta packages” that can be used to pull in whole collections of commonly used packages in one go? Something a bit like “tasksel” from Debian that might provide “standard desktop apps”, “office apps”, etc?
This sounds a bit like a “profile” or module.
If you’re just pulling packages then a profile is perfect, but if you want configuration as well a NixOS module is the usual solution.
I use modules for heavier collections of tools that I only use once in a while, but also for machine specific configuration that share a common “core”. ADB, VirtualBox, and web services for example are things I like to organize in modules.
If you use flakes the
nixosModules attribute is the place to put them.
nixos-hardware have large collections of useful modules you can take a look at.
I’m pretty sure the basic answer is no. I think a lot people here like controlling exactly what is installed. However, I totally think your idea is reasonable and it would be cool to make some NixOS modules in nixpkgs that curate applications people typically want.
This would be an awesome feature for those essentials like:
- common cli tools ( yes I know they are available via programs.*.enable but one by one)
Current structure of nixpkgs with all the categories may be used to “pinpoint” those appliacation clusters.
I do agree that the intention of nixOS deep configurability is to allow user precise control, however certain packages are installed over and over again in scenarios like desktop use. Not all users wish ( or know how ) to maintain a home-manager ( although it is possible to have all of it in configuration.nix ) with a separate config sitting either locally or in git just for that purpose.
Thus little “bundling” but nix- agnostic would actually help to get better adoption across community as it was highilghed during 20th Foundation Community Board Panel.