Linux

You can also use nixpkgs and AppImages on SteamOS.

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:

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.

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.

If you use Nix the imperative way (nix profile blah), you don't need to learn the Nix language at all, or write config files. Installing/removing/upgrading packages is just a single command, similar to other package managers.

Eg:

• To search for bat on nixpkgs: nix search nixpkgs bat
• To install bat: nix profile install nixpkgs#bat
• To upgrade all packages: nix profile upgrade '.*'

Ref: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-profile

For nixpkgs, whike I’m sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.

When you download/build a nix package, nix will absolutely also download all necessary dependencies.

So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix?

Getting a shell with a specific package as a one off. Want ffmpeg? nix-shell -p ffmpeg opens 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.

Flatpak still depends on runtimes though, I have a few different runtimes I had to install just because of one or two flatpaks that required them (like for example I have both the gnome and kde flatpak runtimes, despite not running either of those desktop environments)... and they can depend on specific versions of runtimes too! I remember one time flatpak recommended me to uninstall one flatpak program I had because it depended on a deprecated runtime that was no longer supported.

Also, some flatpaks can depend on another flatpak, like how for Godot they are preparing a "parent" flatpak (I don't remember the terminology) that godot games can depend on in order to reduce redundancies when having multiple godot games installed.

Because of those things, you are still likely to require a flatpak remote configured and an internet connection when you install a flatpak. It's not really a fully self contained thing.

Appimages are more self contained.. but even those might make assumptions on what libraries the system might have, which makes them not as universal as they might seem. That or the file needs to be really big, unnecessarily so. Usually, a combination or compromise between both problems, at the discretion of the dev doing the packaging.

The advantage with Nix is that it's more efficient with the users space (because it makes sure you don't get the exact same version of a library installed twice), while making it impossible to have a dependency conflict regardless of how old or new is what you wanna install (which is something the package manager from your typical distro can't do).