Currently, the official description (c.f. official site, github repo) of nix is a package manager. I think this is potentially misleading.
When people think of package managers, they think of software like rpm, pip, pacman, dnf, dpkg, apt. These traditional package managers does 2 job: installing stuff/filesystem transaction and dependency management: this is evident in distros that have separate tools for these jobs, e.g. apt/dpkg or dnf/rpm.
While nix does the dependency management part, it does not do the installation part. Instead it functions more like a build tool such as maven, cargo, cabal.
Marking nix as a package manager can potentially turn people away because it doesnât make sense to have 2 (traditional) package managers to manage your system (for a live example see this comment). Meanwhile it is perfectly reasonable to use multiple build tools. Also I think it is just generally more desirable to have a more precise description of your product.
I used Nix + Home Manager on another GNU/Linux distro for over a year, which was great. However, I only realized the full potential of Nixâs expressiveness, bursting, and waiting to be untapped when I switched to NixOS and started working on my flake. I will not lie to you: I felt ashamed for having used Nix so shallowly for so long
I used to think DSLs (Domain-Specific Languages) were the right choice for domain-specific tools such as Ansible, Chef, or Terraform; Iâm not so sure anymore. Iâm only a Nix n00b, but from what I have learned so far, one can do all of what those tools do with Nix in a more elegant, modular, safe, and maintainable way.
The learning curve is steepâat least for meâbut enjoyable. And this is gold! There were many times when I had to learn a new toolchain upon joining a new job and didnât enjoy learning some of those tools. Some were easy to pick up and implement but hard to maintain and reuse. With Nix, Iâm in a loop of Excitement â Frustration â A-ha! moment â Understanding â Excitement again. It has been years since Iâve been this happy spending so much time learning a new tech!
I only wish technical people leading platform and automation teams would realize how much value Nix can bring to their teams and organizations by unifying most, if not the complete tooling stack, under a single technology that (I feel) can do everything those other tools do, but better.
I had the same realization recently. And I think this image being a meme of how hard it is to grasp what Nix is doing results from not starting the explanation from the correct location.
I actually had great success explaining what Nix is when I started with Nix being an artifact builder. Itâs one with great properties!
It builds in a super tight sandbox. No access to the filesystem, to environment variables or the network.
To be able to build anything you need inputs, dependencies. Each one must be explicitly stated and will thus be given to you.
You write the output in a location given to you that you have no control of. You have control instead on the layout underneath that location.
The resulting path in the nix store is the hash of whatâs in the output directory added to all the hash of the inputs.
From this, you get nice things:
You get a full Bill of Material up to the exact commit of the bash shell used to compile the compiler youâre using.
If any dependency in the tree of inputs changes, everything that depends on it gets rebuilt.
Patching anything in the build tree becomes somewhat easy. At least you know that everything dependent will be rebuilt without any arcane knowledge of how to build those.
Everything thatâs downloaded from the outside world requires an accompanying hash. This makes the build reproducible in that the outside source canât swap what you download for something else in the future.
Multiple build artifacts can trivially depend on multiple versions of the same dependency as they will simply use different path in the nix store.
Because building an artifact results in a very precise store path, you can actually cache the result for the whole world instead of everyone rebuilding it.
And also, Nix is a programming language so you can use abstraction to build powerful DSLs. You have functions!
From there, we can then add that Nix can build any kind of artifact: binaries of course but also configuration files, systemd files, docker containers, dev environments, qemu VMs, ISOs or full OSes! But here you get the same nice properties for all those use cases.
Thatâs where nixpkgs come into play first: itâs a repository of recipe to build 100k+ artifacts.
Now if you allow Nix to manage your full OS, nixpkgs doubles as a repository of modules that quickly configure the OS. For example, with a few options it can setup a systemd service file, build the related binary and write its configuration file. And all those for everything you install and want configured result in one artifact stored somewhere in the nix store, rolling back is trivial too!
Another thing you can do is have nix produce dev environments. It produces then a shell script that sets up a subshell with everything you asked in the PATH.
Those are all the areas I know the most about. But IMO they all stem logically from Nix being an artifact builder with great properties and everything falls into place.
When I started by saying Nix can produce docker containers, in peopleâs mind they then place Nix as a concurrent of Docker but then itâs hard to see its value.
In fairness, nix pretty much meets the definition of a DSL. It just happens to be that NixOS kicks the established toolsâ asses in all disciplines but standards compliance and learnability.
Without NixOS, its amazing module system, as well as the nixpkgs package repo, nix would be far more limited.
Nix as a build tool is great, but it is not remotely like ansible & co.
NixOS is a deployment tool (i.e., same class as ansible) that is strongly coupled to nix.
My point is that thereâs a bit of a misattribution of which project what features come from; I think itâs important to understand the distinction between the various nix related projects, especially in a thread discussing marketing. Thereâs evidently enough confusion between them - this has been quoted as a marketing problem by people working for the nix-related consultancies before.
Nix is a lot of things. I have a hard time agreeing that Nix is not a âpackage managerâ when we can, as a central use case, use it to download pre-built units of general-purpose software, selected from a list of over 100,000, install them into a global location on our computers, and remove them when no longer used. Thatâs a package manager, or I donât know the meaning of the phrase.
So what if the pre-built part is, if one must be pedantic, retrieving a result from a cache that would otherwise be built locally? Is Portage not also a package manager?
So what if the realpaths of the software have weird hashes that one doesnât typically use directly? The end user goes through /run/current-system/sw or whatever the equivalent is on non-NixOS installations, and Nixâthe package managerâmanages what is available in that path. Should using a global path other than /usr disqualify something from being a package manager?
Would you call bazel a package manager then? distcc? bitbake?
Thatâs not saying I donât think nix is not a package manager - it explicitly has functions for this purpose - but I do believe that it is more of a general purpose build tool than e.g. portage.
It can be both; outside the NixOS context primarily marketing it as a build tool doesnât seem inappropriate.
Rule of thumb: if I think, âHmm, I want to run software X but my computer doesnât have it yet; let me invoke a command from tool Y and then my computer will have it, and later I can invoke a different command from tool Y if I donât want it anymore,â then Y is a package manager.
So no to all three of those things, I think (Iâve only used distcc of the three, so Iâm going off of a cursory glance for the other two), but yes to, e.g., npm and cabal-install, despite those tools also having build-tool qualities.
But I agree that âit can be bothâ is the correct high-level answer. Nix is a big elephant, is my point; we donât need to deny that it has a tail just because it also has a trunk.
While I think this is a fine definition, I donât think this is what people generally have in mind when they say âpackage managerâ. The usual interpretation of the word âpackage managerâ is much narrower.
On the other hand the core functionality of nix works pretty much like build systems: given a build specification/manifest, the nix file, it produces a build output, the derivation.
Markung nix as a package manager can potentially turn people away because it doesnât make sense to have 2 (traditional) package managers to manage your system
Very much my observation as well.
People have learned that, using traditional package mangers, you do not mix and match. You take whats provided with your distro, or you will suffer for it.
Because âNix is the package manager of NixOSâ, itâs exceptionally hard to get people to adopt it in general, even if its not directly used as a package manger.
MacOS users are often more open about it, presumably because of homebrew having already done the heavy lifting (having a third party package manager is fine).
Yes, the trifactor of Nix naming does not help either. I think devenv might actually be a success simply because the project / tool name does not contain ânixâ.
But this is false. People with APT on their system can and do mix and match that with Flatpak, npm, Cargo, and Steam. They learn which package manager they need for which use cases, even though some of those cases may overlap because a piece of software could be packaged for multiple PMs. While there are advantages and disadvantages to this kind of fragmentation, I donât think âyou will suffer if you use anything other than APT from that listâ is a common opinion.
While I agree that a key challenge to both marketing and learning Nix is roughly about understanding what it is (and is not), Iâm not sure I agree with the ânot as X but as Y and Zâ framing.
When I imagine the Venn diagram of people out in the world who might ever use or look for a âbuild toolâ, âdependency managerâ, and âpackage managerâ, I suspect the circle for the latter both dwarfs and almost entirely contains both of the former.
I canât imagine the universe in which I would have found and adopted Nix if it was only marketed as a âbuild toolâ.
That said, I donât think itâs wrong to create marketing material that focuses on different audiences and use-cases. And I donât think itâs wrong to ~audit our terms and language to look for ways we can reduce friction caused by common misunderstandings of what Nix is to make it easier to market to different audiences.
By this point I doubt there is any terse elevator pitch for Nix that communicates what it can do for everyone who could benefit from it.
I suspect much of the trouble around communicating this comes back to the crux of Nix being more of an idea/vision than a thing.
Since this idea isnât drop-in compatible with much of traditional computing, the Nix ecosystem is a messy search for better ways to ~refactor not-Nix technologies into compatibility. Itâs an iterative search for The Nix Way.
At the risk of sounding ~woo, I also suspect starting to grok The Nix Way gets someone closer to understanding what Nix is than rote knowledge of whatâs in the official toolkit?
I agree with the build system framing. The competition isnât so much Debian or RPM as it is Bazel. One could imagine making a BazelOS just as there is a NixOS; I would not be surprised if, due to us failing to compete in the build system space, there is such a thing in a few years.
It takes a bit more time than an elevator pitch, but my introduction so far seemed convincing. Nix does exactly two things:
Nail down the contents of files and references between them, such that when you need to move around the entire collection, you always get exactly that, regardless where you place it
Run executables in isolation, such that they can only access these nailed-down files, and itself will produce only nailed-down files.
The Nix language is just there to orchestrate that, and despite all its quirks, itâs quite useful because it has file system paths and string interpolation as first class citizens, and it turns out that this matches exactly the Unix idea where everything is a text file.
So whenever you want to create new files from a bunch of existing files, consider using Nix, because they will never fall apart, and youâll be able to run executables among those files in exactly the same manner after any period of time has passed, on any machine with a matching architecture. (Then comes a list of typical use cases, such as your thesis where you build a PDF or website from a bunch of files, or an entire operating system, which is also just a bunch of files.)
People with APT on their system can and do mix and match that with Flatpak, npm, Cargo, and Steam.
But they donât mix apt with zypper, yum, pacman or even Ubuntu apt with Debian apt (repositories).
Nix is not perceived by many as a tool that useful as a standalone package manager, its perceived as the NixOS package manager.
Itâs neither universally true nor universally false, itâs an observation Iâve made pitching Nix to colleagues. Itâs one data point out or many. It can be taken into consideration or it can be dismissed as an outlier just the same
If you market nix as a package manager, and NixOS as the distro that uses nix as its package manager, then people will use their own intuitions as to how to do package management on NixOS.
By their intuition, if âinstalling a packageâ on Ubuntu is apt install, surely the analogy on NixOS is nix-env -i. Then they wonder why anything that requires dbus or systemd or even its own config file doesnât workâŚ
NB Iâd say nix-env is inappropriate even on other distros
