Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).
NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.
I don’t get why more people aren’t using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I’m also scared that there is a downside to them I dont know about.
When you download/build a nix package, nix will absolutely also download all necessary dependencies.
Getting a shell with a specific package as a one off. Want ffmpeg?
nix-shell -p ffmpegopens a shell with ffmpeg in its path, and only that shell has it.Along with that, that means users can install packages for themselves. Limited use for single-user systems, but nonetheless it’s possible.
Per-project dependencies. Pretty much the same as above, but the dependencies are declared in a file which is part of the project. In many cases that same file can also be used as a nix package itself, like any other in nixpkgs. Very useful if you write software yourself. Here’s an example.
Being a source-based package manager with a cache means that you get all the benefits of prebuilt packages but can easily patch or use other versions of a package, with no difference in use (other than that it will build it locally instead of downloading from the cache).
On a distro with a different main package manager I would probably mainly use it for per-project dependencies though.
I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.
Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.
The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup). Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.
From my limited experience using home manager under Linux and macOS:
All in all nix seems like a pretty concept but not too practical at the moment.
apt install foo && apt remove fooThat’s essentially what
nix-shell -pdoes. Not a special feature of nix, just nix’s way of doing the above.Actually using it though is pretty convenient; it disappears on its own when I exit the shell. I used it just the other day with
nix-shell -p ventoyto install ventoy onto an ssd, I may not need that program again for years. Just used it with audible-cli to download my library and strip the DRM with ffmpeg. Probably won’t be needing that for a while either.The other thing to keep in mind is that since Nix is meant to be declarative, everything goes in a config file, which screams semi-permenant. Having to do that with ventoy and audible-cli would just be pretty inconvenient. That’s why it exists; due to how Nix is, you need a subcommand for temporary one-off operations.
The last time I used it, I needed arandr just to create a layout with a new monitor. Why would I install it, use it, remove it, and then auto remove the leftovers when I can just run a single line to use it once and forget about it? My old installs were littered with random crap like that that I’ve used once and forgot to remove.
Here’s the last time I used it: I needed to compile some rust binary but I don’t have rust or cargo installed. Since the repo has a nix flake, I was able to clone it, cd into the directory, run “nix develop”, and start compiling. Much easier than having to find and install all of the compile time dependencies, and then remove them a minute later.
Besides that, there’s a reason why python has different 20 venv packages: they’re all crap. Nix is a better alternative and leaves you with a single dependency for every OS.
Declarative package management definitely has it’s benefits, and nix has been growing in that space ever since they’ve added the option to generate docker images from nixos configs. It’s not meant to replace docker, just to give you an option to create finely tuned base images.
Home-manager on Debian: no manual set up was required.
They can get overly long, but perfectly raadable if you start from the bottom.
Nixos sure, but with nix I get the same bleeding edge userland packages on Debian and whatever else I’m running at the time. It’s just a list of packages, but it makes life so much easier.
It’s probably one of the simplest things you can do with it that isn’t really possible with other package managers and also doesn’t require explaining any internals, I guess that’s why.
I could also tell you about easily being able to build statically linked binaries or cross-compile (or both) with the same package definition without having to do any extra work, that might be more impressive.
Yeah, and neither of them considered that it might be important to deal with software written in other languages. Want to link against a C library in a Rust project? Run some tool as part of NPM build step? Screw you, install it manually from elsewhere or your build fails. The only one that I know does do this is OCaml’s OPAM, which does have a lot of non-OCaml software packaged. (Also at least the latter three seem to be only for setting up the language itself. What is this, a package manager for a single package?)
Meh, Docker is kind of a joke. Sure, it solves the problem of dependencies, but in possibly the stupidest way possible bar shipping a VirtualBox image. A lot of prebuilt images are x86_64 only. It needs to run a Linux VM on Mac and Windows (tbf Nix doesn’t have a native Windows version at the moment either, you need to run it in WSL, but people are working on that). So that means running at native performance on an ARM Mac, which are quite common for development I think, is out from the start. It also adds a lot of complexity to your environment due to wrapping everything in a container if you just want to have a couple tools. You don’t get your nicely configured shell, other system tools, anything else inside the container. I haven’t ever tried it but you probably also need special support from any IDE you want to use.
(And not to mention most Dockerfiles being absolutely not reproducible, but you can solve that… with Nix :^) )
On Linux I think you need to link ~/.local/share/applications to home-manager’s share/applications. Not sure about Mac, its GUI kind of hates symlinks and Nix uses a lot of symlinks. Spotlight doesn’t read anything behind symlinks at all, for example, and Launchpad resolves them so after a package update it will not pick up the new versions because it’s still looking at the old path.
Unfortunately true, yeah. I also think this isn’t really a problem that can be solved due to Nix being a dynamically typed language that has everything be an expression (so there’s no fixed structure whatsoever) and also using lazy evaluation everywhere. Three components that all decrease the capability for useful error messages and debugging, and together… yeah it can get pretty bad.
Really? This hasn’t been my experience at all. There’s a couple like that, sure, like the build sandbox on Mac, but they’re rare. And usually people in the community channel know a workaround :^)
So it sounds like nixpkgs is more akin to virtualenvs in Python rather than a traditional package manager. Is that an accurate statement?
If so, I’d recommend that be your selling point because that’s some powerful security.
Virtualenvs for everything that don’t duplicate resources and are reproducible.
Nixpkgs: the official nix repository
Nix shell: only creates a venv with extra packages
Nix develop: full environment configuration on top of nix shell, so you can for example set up project specific envars
Besides that, nix can also work for regular userland packages as an:
imperative package manager (same style as apt install)
declarative package manager (you make a list of packages, nix/home-manager ensures they’re installed)
The selling point for me is that I can just write a list of packages, and have the bleeding edge versions installed on top of Debian. I can git that list and have all of my packages available on every device, no matter the os or distro.
Won’t lie I’m getting sold on this via this discussion
Here’s a part of my other comment because the docs are horrible:
It took me days to get to that point simply because you need to trawl through outdated and nixos resources. Those examples + home-manager manual will get you going in 10 minutes.
For development, yeah you’re supposed to use it like that, as opposed to installing dependencies systemwide. I don’t think you can even really do that on NixOS.
However, it has nothing to do with security though, but rather dependency isolation, so you can use one version of library X for one project and another for the other without them conflicting.
I mean, security is an unintended outcome of it. Any kind of isolation of packages provides a level of security.
Ehhhh, security by obscurity if anything. Every downloaded or built nix package is in /nix/store and readable for every user.
docker run --rm -ti -v "${PWD}:${PWD}" -w "${PWD}" ffmpeggets me most of the way there. I alias commands like this all the time.