> The single biggest huge blocker is lack of support for nix-shell in VSCode and JetBrains IDEs. Every other complaint is a minor trifle in comparison.
For the VSCode case, does the Nix Environment Selector extension not do what you want? https://marketplace.visualstudio.com/items?itemName=arrteria...
> No, not really. [...] [E]xplaining it as "like Python venvs, except works for any combination of programming languages" [...] sets for correct expectation for feature set and complexity.
That's definitely a good description of the development environment use case, for people who know what Python venvs are for. It's also accurate, as far as Nix is about Nix profiles. Nix profiles are like Python venvs.
But all or close to all of the packages in Nixpkgs work just fine even if you have no profile at all set up for them— they behave correctly even if you invoke them directly from their paths in /nix/store. If you look at the install target as `/nix/store` rather than `/nix/var/nix/profiles/...`, then `nix-build` is just a source-based package manager in the ordinary sense which:
• installs each package to a unique, content-addressed-ish prefix
• uses the Nix language and Bash like Homebrew uses Ruby, Portage uses Ebuilds + Bash, MacPorts uses Tcl, etc.
• happens to have a really good build caching story
And your tools that build Nix profiles (`nix-env`, `nix profile`, `nix-darwin` and `nixos-rebuild`) aren't doing package management in the sense of building or installing anything, but instead just build convenient facades (out of symlinks) for accessing all of those packages installed to /nix/store in a more convenient way. The venv-like properties of those facades (symlink forests) just emerge from the one-prefix-per-package strategy of the underlying package manager. (In the case of profile managers that manage services, they also run some activation scripts.)
All of that is not to say that what I outlined above would be a better strategy for describing Nix to developers who just want to take advantage of environments that their DevOps team has prepared for them. I think you've settled on a really good explanation, for the reason that you outline.
If you're the Nix guy at work, you probably already understand what I wrote in this post, and have good reasons for preferring to present Nix to the developers that you support in the way you do. What I want to point out is more for the benefit of others, especially people who've done packaging or sysadmin work with other distros but maybe don't get how Nix works, maybe because they're turned off by all the FP jargon.
The lesson is this: there is an old-fashioned, familiar sort of package manager underneath the tools Nix users interact with. The essence of how that package manager is different from what came before can be boiled down to a single sentence: each variation of every package gets installed to a unique prefix. Once you have that, you can do wonderful things like build in snapshot-free rollbacks; allow unprivileged, per-user installation of packages; or generate venv-like per-project environments; and all of the other cool things Nix enables. Nix's complexity and power both follow from that one tweak, from what it took to get there on the one hand (the concept of derivations and various properties of the Nix language) and what it buys you once you have it (polyglot, venv-like setups and lots of other goodies).