Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.

And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to edit a file, the experiment is not going to last long.

> So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.

I'm not "insisting otherwise", I'm observing that it's confusing, utterly useless, and provides no real guidance towards improvement. And it's where the site told me to go as my second step into nix.

But apparently you're perfectly happy that this is what the "first steps with nix" should be (after having berated me for going there), so... proving the point I guess.

> What? The there are far more chapters in the Nix manual than just the three you mentioned.

Have you actually looked at them? ever?

1 is a quick overview of the entire thing, none of it actually helpful.

2 is a few basic commands expanded upon in (4)

3 is a lot of time spent on installation details

4 is where the meat starts, "You can upgrade package" is 4.1, "profiles are a thing" is 4.2, 4.3 is "nix will eat your disk space" (useless to a beginner), 4.4 is "channels" (even worse), 4.5 is "sharing packages between machines" which could not be less useful at this point./

5 is, as I said, "the nix language" covering the basics, with 5.4 mentioning derivations and going into plenty of details, none of them actually useful or telling a beginner why they should care

Following which we reach 6.1 "remote builds.

From a beginner's perspective, tits on a bull are at least funny, the nix manual doesn't even have that going for it.

Have a nice day, I'm done wasting time on you.

I'd be okay doing that to install packages but what I don't like is the N number of ways to install packages. Do I use nix-env? Do I use the new nix CLI? Do I make an entry in configuration.nix? Do I use this thing called flakes which is marked as experimental but almost everyone seems to be onboard with it?

There's no central and definitive source of documentation either. There's the official NixOS website, nix pills, nixos.wiki, blog posts from prominent developers, and other sources I don't remember.

Seems like a fragmented mess to me.

Indeed, I've been using Nix for many years (on Ubuntu, NixOS and macOS), and I now find the apt-get style 'considered harmful'.

Instead, I define a single Nix derivation ("package") which provides everything I want in its 'bin/' directory, e.g.

    with nixpkgs;
    buildEnv {
      name = "my-macbook-programs";
      paths = [ bash gimp /* etc */ ];
    }

If that's the case, perhaps `nix-env` shouldn't be mentioned as the command to use to install packages on search.nixos.org?

I checked the NixOS manual right now but the last time I did, it instructed to use nix-env to install packages. The declarative package management using configuration.nix wasn't highlighted before as it is now.

This is exactly the kind of thing the parent comment mentioned. I'm not willing to go through these kinds of papercuts to get whatever NixOS has to offer with its radical changes.

Oh, and the nix package manager is still unbearably slow. It reminds me of my (unpleasant) time using dnf. Once you're used to package managers like apk and pacman, its an extremely jarring experience to stare at your screen and wait for a package to get installed.

Well, for one, someone send me a random Python script with a dependency on a PostgreSQL driver (that probably needs to compile some C library). Just the script, no `requirements.txt` or `Pipfile.lock` or `pyproject.toml` files declaring the dependencies. I could have just created a virtualenv and tried to install it using pip, that would probably fail because I don't have a proper C compiler setup. Or maybe I have but it is missing headers. Maybe it will work because there is already a wheel for my system, but maybe it will not because some other random reason.

Instead, I just wrote two lines for shebang:

    #! /usr/bin/env nix-shell
    #! nix-shell -i python3 -p python3 python3Packages.psycopg2

> What problem is Nix solving? What pain does it fix that is so important it would justify me spending 6 months on it?

Really the meme that you need to spend months just to use Nix properly needs to die. I literally skimped the docs and got a working NixOS install at my first try on the system [1]. The default configuration is really well documented with examples, and I think most people can get what they want quickly.

Eventually I wanted to use something that was not packaged on nixpkgs, or I started to want to upgrade some specific packages without using unstable. At that point it was when I started to think Nix was kinda of painful (not because it was difficult to do, however the documentation is not good and you end up searching a lot until you find some answers). At that point yes, it is kinda a journey, but it is very similar to learning a new language: you eventually can get very proficient at it, but you never stop learning.

> And then there is NixOS, which again, I have no idea-- I can create my own Linux distribution that is what, reproducible? Again, is this a real problem anyone faces (and that isnt fixed by docker or ansible or any of the other hundreds of tools)?

Try to have reproducible system with Ansible. Yeah, I tried. It simply doesn't work well. Ansible is always a pain because steps randomly fail in a new machine, and you can waste hours of debugging for simply issues. Not NixOS: if your configuration builds there is a great chance that everything will work.

NixOS is the only system that I am sure that I have the exactly same configuration as my other systems, as long I am running the same commit from my nix-configs repository. Can't say the same for Ansible: if I setup a machine using Ansible right now and 2 days from now, pretty sure they will have different package versions (since the repository will have changed them), for example.

Also, you don't have rollbacks with Ansible. Yeah, you can have ZFS/Btrfs taking periodic snapshots and use this for rollbacks. This is not the same though. The UX in NixOS is simply so much better (reboot your system and select which generation you want to boot).

> My point is: Why is Nix getting so much hype when I dont see them solving any real problems? Sure, they promise a lot, but I have yet to see any real solutions.

Well, my point is: Nix solves real problems. Maybe you are not bitten as much as I am with them, maybe you think that spend half a hour trying to get a random Python script to work is fine. And I completely concur with you. It doesn't mean that Nix is not worth your time though.

[1]: Now, I think the fact that I used Arch Linux before really helped, since both NixOS and Arch Linux have an installation process that is completely terminal based instead of a proper installer.

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).

The nightmares come from pypi packages and their assumptions that e.g. the particular version of `libfoo.so` that happens to be in your `/usr/lib` at the time of installation is the one you need it to link against, which is a very crass assumption in 2023. Nix doesn't hide you from this. But it's quite straightforward to write your own nix packages based on upstream python packages which should work fine alongside other nix packages.

By and large, nix does not play particularly well with other package managers, because the nix view is that it's absurd having 7 different package managers fighting for control of the same system.

Strictly speaking "Nix" may refer to two things, and I'm not sure which thing either of you are referring to, nor if you two are referring to the same thing.

Personally I found the nix package-manager a bit odd, but to me that was not a deal-breaker for trying out NixOS. The bigeset problem for me was lacking packages... I was however willing to help the community out by trying to package the things I needed which wasn't already provided for.

But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point.

And to address your comment: I think I've seen similar comments on HN at regular intervals. It's definitely not a one-off comment.

If they had used another more standard language (like LISP!) I would probably still be on NixOS as my main OS.

In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does).

This is not true. The defining point about Nix is that it allows to define all dependencies explicitly. Every derivation in it is built inside of a sandbox with no access to network and restricted filesystem. This ensures that nothing is accidentally missed. Package management is just one of features.

> Second, to use this package manager, you first need to install direnv. How do you install it? with brew, a different package manager.

direnv is not needed to use Nix, it's just a nice add-on. It's like you don't need Ranger to navigate in a file system, but it is nice. Besides, you can install direnv through nix, I use it this way. Even nix is installed by itself as well.

> Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first.

Well, yes you do, but language is actually quite simple it's the nixpkgs (repo containing all packages) that's quite complex. Nix's purely functional, lazily evaluated properties exactly fit as a language describing dependencies.

> Fourth, finally, we get to install a simple Unix program, that any package manager could have provided.

If you were trying to install a package, you don't need to learn anything, you just install it (for example to install ranger you just run nix-env -iA nixpkgs.ranger). Nix language is only needed if you want to create a new package.

> For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. "Reproducibility!" Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic.

> And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That's only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers.

> Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don't need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else.

Nix delivers what docker promised and ultimately failed to deliver. Docker promised to reproduce developer's environment to production. What it did was to zip developer's computer and deploy it. When docker got adopted, relying on images was impractical, so for deployment Dockerfile was used, but that file is not much different than a shell script.

Nix instead describes the entire dependency tree down to libc. Because the starting state and all dependencies are known it can always create the same result, that's the biggest selling point of Nix to me.

Yah, the more I think about it this is the biggest selling point to me.

>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.

I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)

> No thanks. I'd rather not have to learn an entirely new language just to do things like distribute and install applications.

Common misunderstanding, but you don't need to know Guile or the Nix language to use either of these systems.

"guix install foo", "guix pack -f docker bar", etc.

Guix also has package transformation options ("build with this patch", "build with these sources instead", "replace foo with bar in the package graph") that are exposed to the command line and also don't require you learn any Scheme.

This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).

If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.

Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.

So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.

Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.

This is what confused me the most.

Nix (CLI tools / language syntax)

NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian)

Flakes vs "configuration"

I just wanted to like "terraform apply" a system configuration on my Debian install.

People are obsessed with Nix because you can manage your config for their local system

Ok... Ansible has existed for 12 years? And you can use it on Debian/don't need a full OS/distro from the ground up (NixOS)

But people will come out of the woodworks to tell you how you don't understand, you're wrong, you're missing the point, Nix is the greatest.

Perhaps, if they clean it up significantly, I think that nix's principles are very sound, but the implementation isn't: it's fine when you are using it as a simple package manager but as soon as you want to do something a bit complex (say building gcc with a different kernel version) you're on your own:

1) half of the documentation makes reference to configuration files which aren't in my version of nix??

2) there is no real mail/news forum for support/help: no IRC isn't enough.

On top of this, Nix could be extremely well suited to casual users. It inherently avoids most of the problems that plague casual users of traditional package management tools.

Unfortunately, most of the more serious Nix contributores I have interacted with are in too deep to see the usability problems. Even worse, usability issues get trivialized, and users who ask for basic improvements get talked down and told they just aren't getting the magic of Nix.

For example, the topic of versions has been argued about for over five years: https://github.com/NixOS/nixpkgs/issues/9682

What I was complaining about was the difficulty installing a specific package version. That's trivial with other build systems, but not Nix.

> I don't use [package managers] to install dev dependencies.

I'm under the impression that most people do. Either way, I see the main advantage of using Nix to be setting up dev environments without installing a bunch of global packages, or dealing with a mess of files. Unfortunately, as a user, I find it to be much more of a hassle than it needs to be.

If by "documentation" you mean "community documentation", indeed people like to point out that You-Re-Holding-It-Wrong-And-Should-Not-Do-This-As-It-Is-Not-The-Proper-Nix-Way, with which I disagree because Nix is a tool, and wielding it in a way that solves one's problem is one's prerogative. I do agree that doing it in other more complete ways (e.g configuration.nix, shell.nix, flakes) unlocks further helpful stuff but that does not mean doing it this way is not helpful in its own right, especially as the more complete ways come with more knowledge needed, thus facing newcomers with a steeper learning curve.

If by "documentation" you mean "official documentation", it certainly does _not_ advise against this approach: https://nixos.org/manual/nix/stable/package-management/basic...

> After my initial usage of nix, I switched to following the "best practice" of writing derivations and specifying system dependencies in the configuration.nix .

Which is how it should be, walking along the learning curve: start small, walk forward, and stop at any point that solves your problems in satisfactory ways. configuration.nix is nixos/nix-darwin, but to me that's already a bridge too far to get simple early adoption from newcoming folks.

I find it more friendly to let people start with nix-env, possibly shoving a sequence of nix-env -iA foo in a shell script, then as they get familiar with it, progressively have them realise that they can set up their dev packages per project easily with shell.nix, or their system ones with nixos/nix-darwin configuration.nix instead of lecturing them in doing it "The Right Way".

> If you've used nix enough to memorize them, this probably goes away.

That's my "learning curve" point, and true for any tool. I've seen the same resistance with Docker back then and now everyone takes it for granted, but it was equally mystifying for people at first.

> it's way easier to remember "search" than "--query --available" or "-qa"

I would agree, nonetheless the situation is really not much better for some other package managers that folks seem to have no problem with, e.g pacman is loved yet has an eerily similar --query/-Q, apt-get/apt-cache/dpkg are all over the place in general Debian-based management, including Dockerfiles.

By "have no problem with" I mean I never heard anyone saying "OMG apt/pacman is absolutely inscrutable I cannot use this", which Nix seems to trigger every time.

I will readily admit though is that whatever https://search.nixos.org/packages is doing should be available via command line. Big gripe on my side but it's not an insurmountable barrier.

> Even "nix-env" is sort of weird as a name, because it begs explanation of why "-env"

Is it? People do not seem that taken aback about using "rbenv" or "pyenv" or "virtualenv". I don't think "env" is exactly uncharted territory.

> As for the rest, consider the use case of setting up an environment with Python packages [...] And the problem is, by this point you've long ago lost most software developers

Whoa, this is going much farther than what prompted my initial comment. Fair enough though, I'm the one who made it devolve into project-level management with Python/Ruby dependencies. That said, folding language dependency management into Nix is definitely a very rough area of Nix, one that needs much development to be made easier.

That is exactly why I am advocating for this less dogmatic approach of doing things: have Nix handle your systemwide (via simple nix-env) or per-project (via shell.nix) tools and delegate language dependencies to the dependency tool that people use, reaping both the benefit of nix for setting up a dev env and the benefit of people knowing their tool of choice for their language.

Language dependencies have a huge impedance mismatch between dependency management tools and package managers. There's exactly the same kind of impedance mismatch problem with trying to package some or all language dependencies with a package manager such as apt or pacman or homebrew. Trying to package a gem or wheel in a deb is an exercise in frustration. I don't know if it's still the case but there was a time where npm install -g, pip install --global, or gem install would install stuff where e.g apt or pacman would, and thus screw things up badly.

So I would recommend for a long while: do not attempt to have nix handle everything down to language dependencies at the beginning because the impedance mismatch between these dependency management tools and nix is making it hard. The current state of Nix has no descriptive abstraction on top of it so you are faced with injecting stuff and getting to grips with Nix internals.

I do believe that over time this is solvable though, e.g NixOS modules generally provide nice override points that don't require one to dance with overrideAttrs and self: super.

> They gave up, wrote a dockerfile with `pip install` commands

Interestingly enough, that's sort of what I recommend for newcomers, except not with Docker:

    # shell.nix
    {
      pkgs ? import <nixpkgs> {},
    }:
    let
      # get these python packages from nix
      python_packages = python-packages: [
        python-packages.pip
      ];
    
      # use this pyhton version, and include the above packages
      python = pkgs.python39.withPackages python_packages;
    in pkgs.mkShell {
      buildInputs = [
        python
      ];
    
      shellHook = ''
        # get python version
        export PYTHON_VERSION="$(python -c 'import platform; import re; print(re.sub(r"\.\d+$", "", platform.python_version()))')"
    
        # replicate virtualenv behaviour
        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"
      '';
    }

My point is not that Nix is not hard, Nix can be hard... if you go full-tilt, but it can also be immediately useful even with only small, approachable bits here and there. I remain convinced that the people that spend hours on end cobbling up Dockerfiles full of sed hacks and conjuring contrived docker run commands to run on a dog-slow Docker for Mac should not be objectively turned away by 'nix-env -iA' instead of 'brew install' or even making sense of that shell.nix.

That's why I feel like the community's response in the lines of "don't use nix-env" or "flakes!" combined with "here's this nixlang eldritch horror and I can't seem to be able to do this" is unhelpful in reducing the general sentiment that Nix is only approachable - and thus useful - if you write Haskell in your sleep.

That's why I'm trying to make it better with my limited ways so that curious newcomers are not scared away and can benefit from a little bit of nix goodness with little effort.

No, but it does define how (and where) I will write that code.

It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS.

There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better!

If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.

Sure, this is pragmatic.

> But it seems it isn't able to blindly mirror stuff from pip, for example? Or to just package any linux under the sun, like Docker can? You'd have to have a nix-specific version of every package you want to use.

Building a DEB package with Nix is apparently possible, if quite awkward. https://nixos.wiki/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkg...

The story looks a bit better for images. Packages can run appimages or snaps. https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTo... -- Which seems a decent compromise.

I think the effort of "I have to package this" varies from "automatable" to "PITA".

My experience has been that for writing package expressions for Python packages or Golang applications, it was more/less straightforward copy-pasting that required little Nix understanding. (The effort being: what are the sha256 sums, and what are the dependencies). -- I think to an extent this can even be done by "<lang>2nix".

An example of difficulty I've run into was trying to package a repo where I was unfamiliar with the language, and where build process assumed they could modify $HOME. I noticed that e.g. the anki package had to have a workaround anki-bin in order to get up-to-date versions because anki's build process changed.