>> ... and not have it installed globally is amazing.
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..!)
> Now if we can just get the UX together, it will be incredible.
The crux of the NixOS issue right here. I tried NixOS a few times, even this past weekend, and it was such a pain that I gave up each time!
I am planning to integrate Nix (the package manager) into my recent fresh OS install if I have some time this week. I want to use Nix to have, at the very least, a controllable way to install and remove toolchains of different versions in a reproducible manner; if I can swing it I am going to use it to install pretty much anything that requires any sort of configuration care (the rest I'll just use apt). I also want to integrate more tools like asdf or pyenv which help with that, but I prefer if I could do it all through one package manager like Nix. I finally separated my /home into another drive this time, so that'll be nice for future re-installs.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
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.
> I wish the next generation of linux has a single package manager :(
Package management used to be my biggest frustration with computers. A couple years ago, I switched to nix [1][2] and now use it across all my unix-like systems (not sure how well it works on Windows, I haven't tried). Most under-rated piece of software I use, I'm surprised it hasn't blown up yet.
> When I, like many other computer programmers, tell my friends who don’t write code that “it’s a miracle that modern technology even works”, Nix is one of those things that I’m referring to.
Interesting. Since I've started using Nix for managing my environment & projects, it's the only thing that I'm confident will work. I have no idea how the RPM & DEB ecosystems, among others, work when random dependency breakage can happen all the time. This is extra true when building Docker images whose Dockerfile's second line is almost always `apt-get update && apt-get install [list-of-packages]`. I've had so many problems with that process over the years that I've wondered how anything worked at all. Nix was like some heavenly realm where I could be 99.9% confident the build would work every time.
> Do you get anything when not using NixOS to manage everything? [...] Has anyone gone down this route?
Yeah, for sure! I don't use Nix this way very much on Linux because I mostly just use NixOS. But I use Nix this way on macOS at work every day, because that's the Unix desktop that's available to engineers there.
By not going full NixOS, the tradeoff is that you suffer some minor integration issues, and in return you get some more escape hatches. This is a pretty good option for some people imo.
Declarative system config on non-NixOS is a bit more work, because you either have to write your own sort of metapackages with buildEnv¹ or use a third-party module system like Home Manager, System Manager (that one's in very early stages, so pronably skip it if you're a newbie), or Nix-Darwin. The latter are really nice, but you might have to think about how they plug into things like your OS's bashrc file sometimes, and sometimes their install procedures are kinda wonky.
The other main integration quirk to watch out for on non-NixOS is 3D graphics acceleration. Check out nixGL and you'll be covered for that.
Using Nix for nifty per-project development environments, though, is pretty smooth and basically identical whether you're on NixOS or not. If that's an interesting use case for you, Nix on non-NixOS is worth checking out.
Nix as a package manager for CLI tools that don't depend on the base system, or trying out software without permanently installing it, is also kinda nice on other distros. It's especially nice for running newer software on top of stale distros, but it can also take you in the other direction, which might sometimes be useful on Arch.
I think the head first approach of just committing to daily driving NixOS can be good for some people, and it certainly was for me. But learning your way around the Nix language and developer tools by focusing on developer environments and oddball packages on a foreign OS can definitely make for an easier, lower stakes learning process.
> What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix?
If you're not using Nix for any per-project stuff, you're definitely missing some value, as that's likely among the first low-hanging fruit you'll encounter on your Nix journey.
That said, stacking Nix with other package managers and only using it where it makes most sense is totally viable. On macOS, I use it in combination with light use of pkgsrc and Homebrew. You can definitely do the same kind of thing on Linux.
Nix is a fantastic concept, and I hope it takes over the world. But the NixOS packages are a mess. I tried it for a few months last year before giving up after several packages and even whole collections of packages became unusable even in the stable repository. The repository needs some serious reworking before Nix can really shine.
Would you mind elaborating on this? Maybe I'm using Linux wrong, but Nix seems like a huge step forward fixing a lot of my frustrations. Admittedly, I haven't used it in production.
One huge benefit of language-specific package managers is having multiple versions of packages on the same system and you can choose which you'd like for the project (without changing the OS). I feel like 10 years ago I heard a lot of grumbling about languages like Ruby or Python should just use apt/rpm, but I haven't see any OS package manager put much effort into this use-case (this is ignoring mac/win support). The closest I've seen is something like Red Hat's Software Collections.
Personally, I feel strongly that any software that's critical to your company should be decoupled from the OS. This is borne through painful and much delayed OS updates and following it makes things much easier long term.
My personal use-case is that different projects (working on multiple in tandem) need different stacks of versions. Also giving the ability to swap versions on the fly. Here's one package manager specifically designed for it https://github.com/nerdvegas/rez
Swapping versions in Linux is pretty heavy out of the box (with rpm/apt); download, remove old versions files, write new versions files. Only one installed at a time. a/b comparing libraries is a pain. For the things I need, I build things into folders like libjpeg-turbo/2.0.2 and nasm/2.14.02 and set the ./configure flags to point to these...basically a more ad hoc approach to what Nix does.
> I think the problem with Nix is that it is actually not a package manager but a build tool (that provides some package management utilities). People try Nix with the assumption that it should be as easy as apt-get (for example), but found tutorials with a block of code in a weird language...
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 */ ];
}
The nix-build command creates a symlink called `result`, so I put `/path/to/my/git/repo/result/bin` in my $PATH.
> In the last few years, Nix has gone from a place where I was sometimes uncomfortable recommending it to people to one where I feel like it would be unstrategic not to use it.
Super agree. Been using nix now for six(?) years and always been advocating for it but hesentiant to recommend companies adopt it (unless you can use it to attract talent as walmart did with nodejs back in the day) however with https://devenv.sh and https://nix.dev in the existence the time to amaze is now measured in < 5 minutes. nixpkgs also partially solves sbom topics, enables monkey patching any linux application/kernel/ffi dependency, has the freshest collection of packages (it's more fresh than archlinux by a major factor) whilst all being under CI/CD (shamefully rare in linux land)
I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
[0] which are already an overengineered and under-delivering solution in my opinion.
> Nix is an idea which detracts from traditional package management by concluding that ranged dependency versions actually create more problems than they solve
That may be the right choice for the kinds of packages that Nix targets but not for other language's semantics. For example, I wrote the package manager for Dart and it specifically intentionally does use versions because forked shared dependencies don't play nice with the language's semantics.
> The solution is to provide a system wide daemon which facilitates native installs required for by the language, whereby the LSPM can query and request the installation of packages over a well defined protocol, and the daemon forwards those requests to a system-level PM.
That's a large ball of complexity and dependencies. It isn't clear that that's actually a more effective solution than just rolling a package manager for each language.
> The identity-based approach to dependencies means that when building a package, you're always going to be building against dependencies the developers intended - because they're the same ones he/she tested against.
That doesn't play very well with shared dependencies in many cases.
Ultimately, every package manager has a bunch of policies embedded in it. Things that it just decides are The Way Stuff Should Work. Those policies are heavily influenced by what how the programming language is used.
Trying to find the One True Package Semantics seems like a lost cause to me.
> Unfortunately, I don't have a great alternative to offer. The obvious approach is to either let the users handle dependencies (which you can also do with ugit) or write package definitions for every major distribution. And if I were the author, I wouldn't want to do that for a small side project either.
Well... There's nix. Complete packaging system, fully deterministic results, lots of features, huge number of existing packages to draw from, works on your choice of Linux distro as well as Darwin and WSL. All at the tiny cost of a little bit of your sanity and being its own very deep rabbit hole.
> But I'd like a way to install it on user machines, users who probably don't want to install Nix just for my thing. Nix probably doesn't have a way to make self contained packages, right?
I mean... That's the heart of the problem right there. You can either have all statically compiled binaries (which don't need Nix to run) which have no outside dependencies but result in a ton of wasted disk space with duplicate dependency data everywhere, or you can share dependencies via a scheme, of which the only one that makes real sense (because it creates real isolation between projects but also lets you share equal dependencies with zero conflicts) is Nix's (all of the others have flaws and nondeterminism).
> First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager.
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.
> someone like you or me who's willing to learn a completely new programming language to use an operating system
No, it's the other way. I'm using NixOS because I want to understand Nix better. I want to understand Nix better so that I can help this crowd:
> Most people and developers don't want to be a "participant". They need something that gets the job done.
I met a guy last semester who wasted 4 months of his graduate program (structural proteomics) trying to puzzle out how to run some x-ray laser scattering analysis software that was written in FORTRAN and handed to him on a flash drive. He's the person I want to help. I want him to be able to install nix wherever and type `nix run github:foo/barlasers` and be happy that barlasers works as expected, no need to become a NixOS user.
> Your disagreement represents a niche and if the devs cater to your disagreement then they cater to a small niche.
They're catering to the people who are willing to help them create a useful packaging and configuration ecosystem. Just because they're not catering to the end users of those packages doesn't make them insufficiently empathetic.
The alternative is a really comfy package manager and a bunch of broken packages. That's much worse. I see NixOS as a factory floor, if you wanna get your hands dirty we'll happily show you around, but the "easy button" experience that we're building happens where people press that button, not where it's made.
>I totally agree that nix is the future of package management.
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.
> Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository.
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.
> Most users of anything are drive-by, rather casual users.
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.
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..!)
reply