My Experience with Nix on OS X

Apologies for hijacking a Nix thread, but I'd love your views on our OS X binary package sets[0]. We currently ship over 14,000 pre-built signed packages, all self-contained under /opt/pkg, and easy to search/install/remove using pkgin which has a familiar feel to anyone used to apt-get/yum/etc.

The packages are continuously built from pkgsrc trunk so should be reasonably up-to-date, and we try to be responsive when users need newer versions or packages built with different options.

So far the feedback has been positive, but I'd love to see more use-cases so we can improve the experience for everybody. Thanks.

[0] https://pkgsrc.joyent.com/install-on-osx/

In theory, but there's no package uninstaller and OS X installer packages are neither pure nor idempotent.

While you can remove the files installed by one, there's no straightforward or platform-provided way to undo the changes made by their (generally unknowable) install scripts.

Incidentally, Apple shipped an Xcode uninstaller; written in perl, it used lsbom and pkgutil to collect and subsequently remove the files owned by all the com.apple.dt packages complement the system-owned files or files installed by other packages.

It basically boils down to one thing: isolation.

Everything you use will be described by Nix, no system libraries or commands. The only think you rely on is the kernel of the host.

Not only is my environment almost exactly the same from development to CI to deployment but I can actually copy the program exactly as it was built between them (assuming compatible kernel and architecture). For example when I push to my master branch CI automatically runs a build, tests the code with the exact versions of the libraries it will be using in production then uploads them to a binary cache (which is essentially the nix equivalent of a package server), Now I can just install the program on my production servers and it will use the exact versions of the libraries that I tested it with with almost no reliance on the underlying system.

It's like docker but simpler and more elegant.

At the moment that's broken (the 10.9 SDK is installed in 10.11, then links against some 10.11 libraries, which is blocking mplayer). I don't have the knowledge to fix it.

homebrew and fink have had the same problem (deciding when to link against system libraries and when to try to rebuild) -- hopefully nix will get over this hurdle.

[1]: https://github.com/PureDarwin/PureDarwin

[2]: https://www.macstadium.com/ (thanks!)

    {
      packageOverrides = pkgs: with pkgs; rec {
        all = buildEnv {
          name = "all";
          paths = [
            vim
            fish
            gitAndTools.gitFull
          ];
        };
      };
    }
    

Now imagine you decided that you don't like vim and want to go with emacs. You change the paths to `paths = [ emacs fish gitAndTools.gitFull ]`. Run `nix-env -i all` again. What does it do now? It uninstall vim and install emacs.

Now that you decided you don't like emacs after all and want to go back to vim. You can just run `nix-env --rollback` and it will happily rollback the change it made to the filesystem made by latest nix-env call, as in, restoring vim at where you expect it to be.

This is the declarative nature of Nix. You declare the state you want the package to be (or the whole system, in case of NixOS) and Nix will figure out how to get to that state. default.nix can also do a lot more things, for example, adding custom packages, overriding versions, changing build flags and much more.

Let's say one day you need to clone the whole setup to other machine, you only need to copy this default.nix and run `nix-env -i all` on that machine and everything is reproduced in the way you expected. This default.nix can also be per-project, allowing collaborators to share the same packages (and custom packages).

I don't know if it is "the future", but it has features that would be very welcome in other package managers.