I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS. It's the equivalent of being airdropped into the Romanian countryside with working knowledge of French. I am trying to adapt nix for use with some teams I'm consulting on, and my goal is to make its usage as dead simple as possible for really high value tasks.

I also feel like nix is immediately tangible and beneficial in a way that makes us want to get to the power user level, but I don't feel like wanting to learn, say, kubernetes means one automatically wants to learn to be a cluster operator. The scope and complexity are great, and I have experienced all of the things you have described as well. Now that I am fairly confident in my abilities, I think it's important to make sure we find ways to help everyone get the most out of it, even if it doesn't involve scaling the wall that is the learning curve.

> I think an easy trap with nix is the immediate desire to have it manage everything, which usually involves installing NixOS.

Can you clarity what you mean?

What do you mean by "trap"? Which (if any) of the following concepts factor into your understanding? Broken expectations? Premature optimization? Over-engineering? Lock-in?

Are you suggesting that many users of the Nix package manager "fall into a trap" and begin using NixOS?

What do surveys and/or data show about usage of just the Nix package manager? Combined with NixOS?

Many use cases can be covered just by simple uses of nixpkgs, but it's often alluring to go beyond that. e.g

package manager (whether on Darwin or any linux distro), to have some tools globally available:

    nix-env -iA nixpkgs.${some-package}
per project, most shell.nix can just look like this:

    {
      pkgs ? import  {},
    }:
    let
      some_var = some_value;
    in pkgs.mkShell {
      buildInputs = [
        pkgs.some_package
        ...
      ];
    
      shellHook = ''
        # this is bash, so, whatever floats your boat
      '''
e.g asdf, only much more generic with full non-leaking package management:

    {
      pkgs ? import  {},
    }:
    let
      some_package = pkgs.some_package_1_2;
    in pkgs.mkShell {
      buildInputs = [
        some_package
        pkgs.some_other_package
        ...
      ];
    
      shellHook = ''
        export SOME_VAR="some_value"
        ...
      '';
    }
ruby/rvm/rbenv/bundle exec (example for rails >= 6):

    {
      pkgs ? import  {},
    }:
    let
      ruby = pkgs.ruby_2_7;
      python = pkgs.python27;
      node = pkgs.nodejs-14_x;
    in pkgs.mkShell {
      buildInputs = [
        ruby
        pkgs.sqlite
        python
        node
        pkgs.nodePackages.yarn
      ];
    
      shellHook = ''
        export RUBY_VERSION="$(ruby -e 'puts RUBY_VERSION.gsub(/\d+$/, "0")')"
        export GEM_HOME="$(pwd)/vendor/bundle/ruby/$RUBY_VERSION"
        export BUNDLE_PATH="$(pwd)/vendor/bundle"
        export PATH="$GEM_HOME/bin:$PATH"
      '';
    }
python/pyenv/venv:

    {
      pkgs ? import  {},
    }:
    let
      python_packages = python-packages: [
        python-packages.pip
      ];
      python = pkgs.python38.withPackages python_packages;
    in pkgs.mkShell {
      buildInputs = [
        python
      ];
    
      shellHook = ''
        export PYTHON_VERSION="$(python -c 'import platform; import re; print(re.sub(r"\.\d+$", "", platform.python_version()))')"
        export PIP_PREFIX="$PWD/vendor/python/$PYTHON_VERSION/packages"
        export PYTHONPATH="$PIP_PREFIX/lib/python$PYTHON_VERSION/site-packages:$PYTHONPATH"
        unset SOURCE_DATE_EPOCH
        export PATH="$PIP_PREFIX/bin:$PATH"
      '';
    }
mixing arm64 and x86_64 on an Apple Silicon machine:

    {
      x86_64 ? import  { localSystem = "aarch64-darwin"; },
      aarch64 ? import  { localSystem = "x86_64-darwin"; }
    }:
    let
      foo = aarch64.foo;
    in aarch64.mkShell { # this makes nix-shell drop to an arm64 shell, change it to x86_64 to be intel/Rosetta2
      buildInputs = [
        foo
        x86_64.bar
        aarch64.baz
      ];
    }
using an unstable/pinned/git package:

    {
      stable ? import  {},
      unstable ? import (fetchTarball http://nixos.org/channels/nixos-unstable/nixexprs.tar.xz) {},
      pinned ? import (fetchTarball https://github.com/nixos/nixpkgs/archive/ca2ba44cab47767c8127d1c8633e2b581644eb8f.tar.gz) {},
      git ? import (fetchGit { url = "https://github.com/nixos/nixpkgs/"; ref = "refs/heads/nixos-unstable"; rev = "ca2ba44cab47767c8127d1c8633e2b581644eb8f"; }) {},
    }:
    let
      foo = stable.foo;
    in stable.mkShell {
      buildInputs = [
        foo
        unstable.bar
        pinned.baz
        git.qux
      ];
    }
selecting a particular C/C++ compiler&stdlibc++ version:

    {
      pkgs ? import  {},
    }:
    let
       clang = pkgs.clang_12
    in pkgs.llvmPackages_12.stdenv.mkDerivation {
      buildInputs = [
        clang
      ];
    }
The trap is: You could handle all of that by using or writing nix features. You could even use NixOS instead of whatever distro you're used to. But then by going cold-turkey you have to learn whatever nix feature on top of all the basic (as in fundamental) things nix has to offer. Purists would say "no no no this is not the sanctioned way", which is kind of true but also setting yourself up for failure; it'd be like looking at a mountain and trying to jump right to the top, which of course you will fail to, when you could just be climbing it and be successful. Whatever practical gets you on board is fine. You can get to the "pure nix" stuff later, if you ever need to.