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.
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 :^)