Live data from Hacker News

My Experience with Nix on OS X

mpscholten.de

21–30 of 60 posts

Re: My Experience with Nix on OS X

#21
post #5

I'm guessing one of the major reasons more packages are "broken" for macos is there is a CI system running for linux/nixos (travis) and not one for macos. So macos breakages can slip in easily. If a passionate mac advocate wanted to take on the responsibility of setting up & running a CI machine and hooking it up to the github PRs, I can only imagine it being a good thing...

the major reason for poor package support is low number of osx users (hydra - nix build farm - builds binaries also for osx).

I've started looking at this. Part of the problem is that nix wants (reasonably) to do "everything itself", including (for example) bundling the OS X SDKs itself.

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.

Re: My Experience with Nix on OS X

#22
post #16

Earlier quoted context omitted.

How would you run Atom on a Linux desktop without X11? Honest question; I didn't think Wayland/Weston were far enough along yet...

He probably already had X11 installed and Nix was downloading duplicate libs.

This is a feature. Nix is completely isolated from the host system. It manages its own dependency tree. Using libs and other things from the host system would be both brittle and nondeterministic, negating the reason why Nix is so novel in the first place.

Re: My Experience with Nix on OS X

#24
post #23

What do people do about packages being old? Many of their front facing server packages are not being updated. Presumably, they have quite a few security issues in them

Updating packages is generally easy and takes 10 minutes of your time (including sending a pull request) once you've figured out how it works. Please do so if you're a NixOS user - NixOS has far, far fewer people working on it than, say, Debian.

Re: My Experience with Nix on OS X

#25

Earlier quoted context omitted.

He probably already had X11 installed and Nix was downloading duplicate libs.

This is a feature. Nix is completely isolated from the host system. It manages its own dependency tree. Using libs and other things from the host system would be both brittle and nondeterministic, negating the reason why Nix is so novel in the first place.

... except on OSX. Really I just wanted something to take the place of an Arch Linux AUR helper, the way Nix replaces Homebrew.

Re: My Experience with Nix on OS X

#26

Earlier quoted context omitted.

the major reason for poor package support is low number of osx users (hydra - nix build farm - builds binaries also for osx).

I've started looking at this. Part of the problem is that nix wants (reasonably) to do "everything itself", including (for example) bundling the OS X SDKs itself. 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 lib…

Is it possible to avoid bundling old sdk and use the one installed instead by xcode instead? Or it would require too much troubles?

EDIT: completed sentence

Re: My Experience with Nix on OS X

#27

Earlier quoted context omitted.

the major reason for poor package support is low number of osx users (hydra - nix build farm - builds binaries also for osx).

I've started looking at this. Part of the problem is that nix wants (reasonably) to do "everything itself", including (for example) bundling the OS X SDKs itself. 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 lib…

The correct answer for Nix is to never link against a library provided by the system. Nix provides its own bootstrap binaries and it must be done that way for the sake of reproducibility.

Re: My Experience with Nix on OS X

#28

Earlier quoted context omitted.

I've started looking at this. Part of the problem is that nix wants (reasonably) to do "everything itself", including (for example) bundling the OS X SDKs itself. 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 lib…

The correct answer for Nix is to never link against a library provided by the system. Nix provides its own bootstrap binaries and it must be done that way for the sake of reproducibility.

This is exactly what Nix does, but not all libraries are currently 'Nixified', and the ones which are aren't consistent.

Apple doesn't help this -- they want you to just install xcode and the most recent SDK and nothing else.

Re: My Experience with Nix on OS X

#29

Redesign of nix command line is a good thing. Nix should be more intuitive. I totally agree that nix is the future of package management.

What makes Nix the future of package management? I'm not familiar with it so I don't know! I looked at the web-site and didn't find it clear what it does that Homebrew doesn't, other than being cross-platform (although I recently started using Linuxbrew which has made Homebrew cross-platform-ish for me).

The power of Nix start when you start building your own ~/.nixpkgs/default.nix (but you don't really need to if you don't want to):

    {
      packageOverrides = pkgs: with pkgs; rec {
        all = buildEnv {
          name = "all";
          paths = [
            vim
            fish
            gitAndTools.gitFull
          ];
        };
      };
    }
    
This is the Nix package collection. You can install this package with `nix-env -i all`. What does it do? Install vim, install fish, install git. Not much, and easily doable in Homebrew in much fewer keystrokes.

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

Re: My Experience with Nix on OS X

#30
post #11
post #8

Earlier quoted context omitted.

Good suggestion. Looks like travis already has an OS X build environment[0]. So technically it should be doable :) [0]: https://docs.travis-ci.com/user/osx-ci-environment/

Yes Travis CI supports OS X and we used it for a while for Homebrew.

The real solution is we need to use our CI, Hydra, to build all PRs.

Now Travis doing this is interesting because last time people looked there was no hosting for OS X that wasn't ridiculously expensive, so we've literally had people donate Mac Minis.

Post reply on HN