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
But wait, can you do a lot of complex and also deterministic configuration with Bazel? (I don’t know as I have never explored it. I’ve done builds with bazel, but not OS config)
As far as nix is concerned we are just “building something”. Take in some text files and spit some other files out. I don’t see why bazel couldn’t do the same.
No you can’t, but so long as people don’t use Nix to do fine grained builds (and almost no people are trying to do this, sadly) Nix will be seen as a lousy tool for development.
I am using nix to do builds, but only at the granularity that “out of the box” nix supports
Coming from the other end of the spectrum, where people don’t use anything but let’s say bash scripts or Make, nix is often a step up. They don’t have to rebuild every time if they are caching builds in CI, and they can build and try out many variations of dependencies. So it can be kind of a “gateway” toward bazel-like experience.
What needs to evolve in nix to get it all the way there? Implementing a content-addressed Nix ? Anything else? Are there existing builders that do what is needed that could be used by Nix for this purpose?
I think in some respects the barriers really are more social/marketing/etc. We have a content-addrsssed Nix. We have the hydra patch (just need to turn it on). What we don’t have is people trying to use Nix this way (except for a few counter examples, not all open source), skipping stdenv.mkDerivation etc. And we don’t have the equivalent of Bazel’s “rules” repos — but that’s userland.
