New users are using NixOS wrong (and it's our fault)

These examples are generated and beatified , that’s pretty ‘clever’… but i guess there’s only so many comments you can fit into a .nix until they become quite horrific to look at… You couldn’t for example give a use case for something like that within .nix comments. It actually makes sense why the examples are so short in the manual.

Inline comments are not documention, and shouldn’t live directly in the code… but the fact that it does this is testament to the whole automation in nix. :slight_smile: .

Maybe i can automate myself out of job one day…

Thanks to the llamma… for documentation… or attempting to give examples for functions.

so is it documented , or as i said… or is it?

Hi Jon!

Thanks for your effort, I was actually closer than I thought from reading docs.

Though one thing here that is unclear is where clangStdenv is declared and defined and how it relates to the normal stdenv. How nix-shell knows to “use” the clang stdenv just because we called a function on this.

There were some syntax errors in the example you sent me but i got that resolved. I’ll be posting a new thread about cmake and boost.

Thank you so far! :slight_smile:

1 Like

I typed it free hand into a textbox :slight_smile:


Is Nix even designed for the average user ?
I don’t see why a distro hopper should care to use Nix.
Let’s know our customer / preferable user.

Nix does best when it’s:
SRE/devops at companies or hobbyists who have a purist view on running their home server / laptop.

Let’s be frank, for many users Ubuntu or Fedora is just better suited.
We should lean into the users that excel the best and provide them even more reason and tools to do so.


Yes, I think as well that nixOS is not for the average user. Though distro hoppers and other kind of videos that “test” nixOS and make it appear to be harder to grasp than Gentoo do us no favor.

We as a community have to point out, that it was using nixOS wrong and that you have to think differently or we will somewhen have an image of the system that makes everything more complex than necessary, rather than the system that has puppet/chef/ansible as well as terraform built in… Even for the DevOps…

1 Like

Even if we just target power users, we should try to minimize onboarding pain as much as possible. If people like the declarative nature of Nix, then they’ll stay, if they prefer other distros, then they’ll switch anyway.


SRE/devops at companies or hobbyists who have a purist view on running their home server / laptop.

It is not so much a purist view, wanting some niche tools to be installable without breaking the main system, or maybe being able to benefit from mixing fresher and more stable versions of various stuff despite conflicting requirements w.r.t. basic libraries.

But in any case being qualified to know what exactly you want, and also wanting some minority thing (which often but not always comes with the previous part), is probably necessary to benefit from Nix, and also highly correlated with being able to learn Nix with reasonable time investment.


While reading this thread two ideas popped into my mind:

  1. Add a nasty red warning when users are abusing nix-env
  2. Having NixOS “flavors” much like other distros do. In the context of NixOS, I’d imagine that as some sort of easy to understand NixOS “rice” bundled as part of the installer where you can select some preconfigured DE/WM and start from there.

I was thinking of just making this possible through a calamares installer. NixOS is already very much a “choose-your-own-adventure” like Distro.


How do you want to identify “abuse”?

home-manager uses nix-env to “install” the created environment into the users env.

Do you want to show that warning now to all home-manager users that indeed do everything “right”?

1 Like

Yeah, calamares installer sounds great.
And what I pretty much meant is to just give users an example on which they could build upon. (Learn by example kind of thing) NixOS is very unique and I feel like that would be helpful. Might be just me

Yeah, you are right. I have not thought about that. Unless you’d add an additional argument to disable the warning? but yeah… at that point it’s just weird

Your 2nd point remind me of a comment from another post:


I am not sure it does, and if it does, is it actually -i or --set?

I’m pretty sure it does…

nix-env -q lists home-manager-path as installed package, and also grep nix-env $(which home-manager) lists 2 occurences of nix-env:

$ grep nix-env $(which home-manager)
    outPath="$(nix-env -q --out-path | grep -o '/.*home-manager-path$')"
            $DRY_RUN_CMD nix-env -e home-manager-path || true

And even more in a freshly built config:

$ cd result
$ grep nix-env activate
        nix-env --list-generations --profile "$genProfilePath" \
    nix-env --version
$DRY_RUN_CMD nix-env -i /nix/store/d46458gjl39laadvi4zr4c8hns4c1cwd-home-manager-path
  $DRY_RUN_CMD nix-env $VERBOSE_ARG --profile "$genProfilePath" --set "$newGenPath"

And it seems to use -i and --set, though as I do not use nix-env I am not actually sure what that means or what the difference is.

1 Like

Interesting, thanks. I guess this is a special case that is easy to distinguish because -i is applied to a filesystem path and not warn about…

home-manager uses it for the “generations”, this also manages gcroots.

That would explain --set, but it also uses -i to make things available via the Nix profile mechanism and to avoid needing to source an extra thing in the user’s shell profile/rc