How does that work? Will it download ranger, make it available in the shell, and throw it away when you exit the shell?

Yes. (Docs at https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3....) Although it won't "throw it away" in the sense of uninstalling it; it's just that when you exit the shell, you'll be back in an environment which doesn't have the symlink to `ranger` on the PATH.

Seems super useful for one-off tools. Thanks a lot!

It basically garbage collects it (you can run it through a periodic service, or call it manually). You also have older versions intact, so you can simply change back to a previous version instantly.

Also, this is the only package manager where I could reliably install gnome and plasma, and have it removed to the last package - pacman and everything else will leave behind random files all around the place.

I don't think even nix can purge random config files those DEs throw in $HOME

Well, it can’t help random spamming, but home-manager actually can help here! You can have a declarative config for your home dir and it will symlink config files into your .config folder. Also, it will by default never overwrite any file, but it will ask you to remove spammed configs over which you want to use your own, and since these are symlinks, they are read-only so no program will change them (which is good and bad, because it means programs can’t be configured through their gui settings for example)

it's really useful if you work on projects that need different version of dependencies, as you can define on a folder basis what jdk or python versions you want to have. You can even commit this to git so that everyone has the same env locally

For non-nix usage, I use a docker container with debian in such cases. Just docker run, apt install, keep using while needed, then stop and rm the container. Works great to keep the main OS clean.

It'll still be there, but the symlink will go from your path. The nice thing is that if you open another shell and use it again, it's already there, and the symlink is reestablished. If you want it installed globally then it's still there and it just gets added to your path.

If you start to run our of disk space, then a quick garbage collection will remove all unused packages and builds.

The other nice thing about the nix-shell is I can incorporate pip into it (and probably other package managers as well, though I rarely use anything other than Python). So I can open a shell, add various lib type dependencies and any Python packages I want. All of it is only available in the shell, and when I exit they're gone as far as my OS is concerned.

You could clone a repo that contained my default.nix file, jump into a shell and be working with and identical environment to mine.

I have no idea why everyone isn't using NixOS.

> I have no idea why everyone isn't using NixOS.

Well, in my case it is because Nvidia Jetson's line of products is forcing me to run Ubuntu.

I tried. I didn't feel like spending days learning their custom config language just to install a program I want to use. Ease of use is not a label I would apply to NixOS.

Try NixOS with the new redesigned command line. It's much simpler. No idea why this is not getting advertised more widely, as it's been worked on for a few years already: https://github.com/NixOS/nix/issues/779

For example, opening a temporary shell with, say, GIMP, is as simple as: nix run nixpkgs.gimp

If you want to check what packages are available for GIMP, because you are not sure what to run: nix search gimp

I tend to forget very convoluted commands, and I find the new nix much simpler than pacman or apt.

Documentation has also matured a lot, see: https://nixos.wiki/wiki/Resources

Where are the docs for the nix command?

thanks!

It's kind of nice. So everything in nix revolves around /nix/store

This is where each package is stored in a form <hash>-<package name and version> The second part is only useful for humans and is not really necessary. The hash is computed from package source, compilation flags, dependencies, architecture etc. (there's also experimental mechanism where you can use hash that is computed from the contents of the package, which solves some important problems).

The reason why hash is used, is so you can be able to have not only multiple version of the same package, but you can also have even the same version that maybe even depend on a different package.

For example in a traditional system you could have situation that you need to run two apps, but each of them perhaps depend on a different version of openssl. That situation is generally not possible with some kind of tricks, you either have to recompile one application to use the same library or you will have do some kind of tricks, like compiling statically, or placing openssl in some other location. In Nix you can have two openssl side by side and each package is referencing the one it was compiled with.

The store also is designated that it supposed to only adding packages or removing, you no renames and definitively no changes of the files there. If you do that (well it's linux, you can also change permissions and do that if you really want to, but you're asking for problems)

Now this makes caching easy. Because when you need an application you not only know its name, you know down even to compilation of the flags what it needs to be. So you can simply compute the hash of it. So when it is needed Nix will first check /nix/store. If the package is there, success, you use it, if package is missing, nix can contact configured cache (which can be even an S3 bucket) and check for the package. If package is there it'll download and extract it in your store. If object is missing in remote cache, then nix will begin downloading source code and compiling, because that's how every package is defined (how to build it).

Now that explained the basics, when you invoke nix-shell to enter. The Nix will perform these steps, it'll check if you have the package in your store, if it is missing it'll download from cache, if it is missing in the cache it will begin building, if another dependency is needed it will do that step to it recursively.

Ultimately when the package is present nix-shell will enter a shell, with modified PATH that includes the package(s) that you referenced. You exit the shell you land back in old shell with old PATH. If you use nix for development you can also combine it with a tool like direnv, which can make it so when you cd into a project directory it will ensure that your dev tools are automatically available. And they will disappear when you exit it.

If you were paying attention you might realize that this approach will generally make /nix/store just continue to grow, the new packages are being added all the time. This is especially when you use it for development and you're changing your application, you will get tons of versions of the single app. That indeed is happening and is kind of a drawback, but there's a garbage collection method which you can invoke manually, or you can also schedule it to run periodically. There is also an option (I think more useful for a build machine) where you can specify how much disk space you want to use it, and it will just clean old stuff as you're hitting the disk usage limit.

Anyway, changing PATH is what nix-shell does (originally author said it was meant for debugging (you could enter shell that was used for building the application so you could troubleshoot why build is failing), but it turned out a great feature of its own). NixOS on the other hand works in a way that you have central configuration system where you have a configuration.nix file with all system configuration. When you invoke nixos-rebuild command (typically called with switch parameter to immediately switch to the new config) the NixOS actually is rebuilding the entire system from scratch, the only reason it does not take so long is because all needed files are mostly already in /nix/store and all NixOS needs to do is to recreate symlinks in the root to point to proper packages. This is great, because:

1. you get system exactly as described, unlike SCM like saltstack, ansiblem chef, puppet the nix configuration is truly declarative, and not just imitation of it. For example if you define a package in the configuration file and configure system, then remove that package, after rebuild that package won't be referenced anymore and available (it still will be in the store, but it would be just taking space that you can reclaim with GC)

2. because symlinks are used, and packages aren't replaced in-place. You can actually make a rollback. Let say you have your system running and you want to try Wayland. You make changes to the configuration to install it, maybe the process failed for some reason or you realized you want restore things back to where they were. You can just revert to a previous version. This also will be a very quick process since you likely still have your old packages installed and nothing new needs to be downloaded.

It's really a new very different way of thinking about packages and about OS, and this approach solves so many problems with the status quo we have right now. Also, removes need for the SCM tools as mentioned above.