I can only guess here. But remember that software package management was a pain too and it took someone to do a Ph.D. on the topic to give us NiX (and it still isn't perfect).
Ahhhh, Nix/NixOS. The package manager/OS that I so desperately wanted to love.
I stuck with Nix for about six months. I even became a package maintainer.
In the end, I gave up for three reasons:
1. Documentation is really bad. It's often confusing, incomplete or just plain wrong. What drove me crazy is the extreme imprecision with which certain fundamental concepts are referred to. For example, "derivations" are among the basic building blocks of Nix's package management system, yet I counted at least three unrelated ways in which they're referred to within different parts of the documentation. There were also many times when the only way to solve routine problems was to get in contact with Nix's developers.
2. I never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix. Take Node packages. The norm is to install in a project's node_packages directory, and many packages rely on that idiom just to function (e.g., hardwired to import modules with that particular directory structure in mind). Nix attempts to translate each ecosystem's idioms into its own system by introducing many helper functions (all written in the Nix language, very few of which are documented) for each ecosystem. The problem is more fundamental than the fact that this approach is only partially successful and many packages remain subtly broken. The real problem is that there's no unified meta-approach or design language to rationalize how each ecosystem's idiosyncrasies are assimilated. The API's for each ecosystem's Nix helper functions are totally different. You end up as a "Nix Node package developer" just to do your job as a web developer, and then a "Nix Python package developer" just to add a Python package, and so on.
3. The developers don't seem to have any interest in solving these UX problems. They are quick to respond and welcoming people, but the impression I was left with is that they're mostly academics or just interested in whatever subsystem they're working on. For example, when I was working on Nix, the canonical mechanism for updating a single Node package in the Nix repository was to run a script that updated all (yes, all) Node packages in the repo. When I pointed out all the ways that this was an impractical approach, the response was that it's actually a good thing because that way the Node packages in the repo don't get get stale (!) This was one of a few examples I encountered where the devs didn't seem to be aware of how unusable Nix was in real world cases.
My mini-review is from the perspective of someone who was willing to put in the time to jump through all the hoops. I've left out obvious issues that would be a showstopper for many (e.g., obscurity of the Nix language, poor support on macOS). The issues that I've listed are "fit and finish" issues that at a glance may appear superficial, but having worked in the community for a while, I came to believe are more fundamental. They're about governance and what the community wants from the project. I don't believe that their goals are aligned with those of most devs who probably want a system that solves one of the biggest pains in tooling, package management.
It's a pity because Nix's design is really ingenious. Making a "functional" package manager in and of itself is a huge achievement. What I didn't appreciate when I started using Nix is how it normalizes the act of programming your package manager. It's like shifting from Heroku to CloudFront except with much worse docs. The idea is brilliant, the promise is there, but the team doesn't seem interested in turning the whole package from a project into a cohesive product.
You're stating a lot of interesting opinions, but I do not see any arguments to help describe why you feel that way. How exactly is Nix monolithic or proprietary? And what is complicated about it? It seems pretty simple to me, if not at odds with how other package managers do things. It's one of the few package managers that can successfully work across multiple Linux distributions, some BSD systems, MacOS, and even Windows for some software. In my opinion it's the least proprietary or monolithic package managers around, the other being Guix which follows the same principles.
But I think the biggest issue is in your last paragraph where you don't describe why or how the solution needs to happen in the software itself rather than at a higher level.
The thing about Nix is that it's the first project, as far as I know, that tries to solve the problem of package management with a fundamentally different approach. Most of the solutions to date were just okay: they worked with a tolerable degree of failure.
A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9.
Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about.
Disclaimer: I am not associated with Nix in any way.
I've tried to use Nix on and off for years. I always run into issues where I need to write some package and
(1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible
(2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixpkgs is huge for those who don't know) for invocations to find the variable that gets passed into that function and then grepping around the repo for the function that produces that variable and so on until you get to the source type. Things have awful names and documentation is sparse.
I'm a big believer in Nix as an abstract concept, but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences. I would think I'm doing something wrong, but so many people have corroborated my experiences and when I bring specific issues to experienced Nix users they also get stuck.
Ultimately, I've reluctantly gone back to dealing with Docker and system package managers because their failure modes are rarer, more predictable, and more easily worked around.
Honestly surprised the article didn't mention Nix or Guix. Seems like functional package management solves the exact problems the author is worried about.
Nix is... tough. I really want to like it, but every time I pick it up I end up having to write some custom package definition for some obscure transitive C dependency with its own snowflake build system. Couple that with poor documentation for existing packages, the terrible search engine experience ("Nix" and "Nix packages" usually turn up things about Unix or "Congress Nixes Aid Package"), and a thousand other papercuts and it just seems to create more problems than it solves. I dearly hope this changes.
Well, Nix mostly solves that issue so well due to a continuous massive offering of blood and sweat though, let's not kid ourselves. It's a significant amount of work to package arbitrary software because arbitrary software does weird and bizarre things.
But IMO the fundamental principles underlying the design are sound and granular compared to most of the alternatives, though, that's for sure.
I think it's well known, that Nix has a lot of implementation related problems that prevent its mass adoption. They are fixable, but only by different people and in a different package manager. By those, who care about UX and can understand that learning some weird functional programming language and its ecosystem to do basic package management is not ok, but who can still appreciate Nix's ideas.
Reading your linked post, it seems you are wrestling with how Nix works.
Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do.
As the overriding example shows, the versions are pinned by hash and are stored in a file.
What about it is not maintainable or scalable?
Also people forget that the Nix philosophy doesn't end in the package manager Nix, there's also NixOS which takes a functional approach to configuration management of the whole OS. And many other things.
As a Nix user, it's depressing to see that the rest of the industry due to terrible package managers has fallen into terrible trade offs between "not writing the same thing again and again" and "understanding what the hell is going on and not being an alienated pretender".
Really a bummer; this is the rare case of a social issue that does have a technical solution!
I wanted to like nix, but its just too complicated and inconsistent for me to ever recommend it. If my team adopted it, there would be one nix guy/gal that did everything because no one else would bother to learn it.
Also they seem to have alot of breaking changes in the cli. It's basically unlearnable at this point because none of the tutorials or examples work since they were written for a previous version.
Nix seems like a good idea, but the implementation is just a mess. It reminds me of the messy inconsistent AI/ML code I see coming out of academia.
I'll revisit when they have a single executable, that makes the simple things simple like every other package manager. `nix search mypackage` and `nix install mypackage` shouldnt be so difficult.
reply