Why aren't more people using NixPKGs?

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.

You're viewing a single thread.

114 comments

Inate complexity that keeps moving as they introduce things like flakes.
Its a declarative configuration management system as package manager. Thats a lot more to handle off the bat than normal linux + flatpak.
- Inate complexity that keeps moving as they introduce things like flakes.
  Flakes solve the problem of reproducibility for which nixpkgs (or other external input) revision to use (e.g. in a software project). The main thing they bring is a npm-like lock file and a predictable interface. You don't have to use them if you don't want that.
  Its a declarative configuration management system as package manager.
  No it isn't. That's NixOS, which is another thing built on top of Nix and nixpkgs. nixpkgs is first and foremost a package collection.
  
  Say, did nix take inspiration from. npm? That would certainly explain a lot of things...
  
  Nix is 7 years older than npm :P
- It is a whole ecosystem:
  Nix the package manager
  Nix the functional language used to declare packages and configurations
  NixOS that has the package manager and a system configuration in the functional language
  Home Manager, which provides a configuration on the user level and can be used on NixOS as well as other distros and MacOS
  To start out it's completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak
  Flakes explanation:
  The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.
  The problem is that the channels aren't very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don't provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you'd need to either import nixpkgs from the system's channel or import the url of nixpkgs with a specific commit ID.
  Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the "inputs" section and your outputs in the "outputs" section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can't use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.
  Flake example with Home Manager:
  undefined
  
  My Flake Repo/ ├── flake.nix - nixpkgs input and home manager configuration output ├── flake.lock - generated by nix └── home.nix - home manager config import from flake.nix
  Here the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run home manager switch --flake ./My Flake Repo to use that config from the flake. To update run nix flake update.
  
  I appreciate the breakdown, but you've basically made my point for me.
  The above, with its many advantages, versus:
  Sudo apt install X Y Z G F P -y
  Simple, clean, gets it done for near anyone.
  
  Sudo apt install X Y Z G F P -y
  Debian 12 came out last June. In December the version of docker that's shipped by Debian stopped being supported, and is now like 4 major releases behind nix. Debian won't update it for at least a year and a half unless there's some major security patch.
  Besides that, when Debian 13 gets released and I reinstall, I can just clone my dotfiles and use a single line to reinstall all of the packages I need. All of the packages are in a single list, and so there's no more need to run health checks because I forgot to reinstall some random editor dependency for a language I use once a year. If I added it to the list it's going to be on every machine running that list.
  
  Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing. The question we all have to ask ourselves is "is this worth it?"
  I'd say in your specific "docker centric while using debain" use case, sure. Most people who use linux as a daily driver? Maybe not.
  
  Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing.
  What are you talking about?
  It's just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.
  To update everything nix related I just run:
  cd ~/dotfiles/nix/ && nix flake update && home-manager switch
  Sure, it's slightly more complex than clicking a button in Discover, but it's not rocket science.
  I’d say in your specific “docker centric while using debain” use case, sure. Most people who use linux as a daily driver? Maybe not.
  I'd say you've never seriously used a stable distro if you don't realize how common issues like that are.
  I'm pretty certain the current hype for stable distros is fueled primarily by the growth of tools like flatpak. So, since linux users require an additional PM, the real question is: Are you using linux only for browsing and the occasional text editing?
  
  Not to mention that the most common problems it solves can be solved by installing packages from source in a prefix like /opt or ~/.apps and symlinking them from a central place like /opt/.system or ~/.apps/.system or whatever.
  I had a bash script 15 years ago that automated most of this. (Which gradually fell out of use when Arch and makepkg came along, but I digress.)
  I can't help but feel like nix is a solution looking for a problem and solving it in a way that appeals to a certain kind of hobbyist but not so much to any practical purposes. Otherwise it would have been adopted more widely by now.

114 comments

Flakes explanation:

Flake example with Home Manager: