
My Experience with Nix on OS X - _query
https://www.mpscholten.de/nixos/2016/05/26/my-experience-with-nix-on-osx.html?
======
iElectric2
Disclaimer: Nix(OS) developer, I am biased.

It's very important for us to get such feedback. This allows us to improve and
move forward.

In Nix defense I think it's not worth comparing stability yet, although that
is the most important aspect for users.

What matters currently is how many smart people grasp the idea why we're
fundamentally better by architecturing the language and packaging problem
itself and any help we get to move us forward.

For fair comparison you should note that we have ~800 contributors, probably
more than 90% are on Linux. Meanwhile Homebrew packages have almost 6000
contributors.

We have recently added 4 macs to our build farm at
[http://hydra.nixos.org/machines](http://hydra.nixos.org/machines), but we
desperately need more developers _that care_. Not 6000, just a few more.

~~~
CJefferson
Is there an easy overview page to see packages which are failing to build on
Mac, maybe even with a link to the failing build output?

------
kevincox
I've never used Nix for OS X, but I can confirm that the UI can definitely use
some work, and the proposed changed which are in the pipe look fantastic.

But, comparing Nix on the simple operations is like reviewing a sports car
after only driving it in a school zone. There is so much more that Nix
provides that homebrew doesn't even come close to.

Nix has made managing of my servers way easier then anything I have tried
before and I have no intentions of changing away any time soon.

~~~
curun1r
I tried Nix on OS X after a recent HN topic suggested it. I hate Homebrew with
a passion (it's fine initially but, over time, it's always created a hard-to-
clean-up mess for me), so I was looking for something that could replace it
for most unixy things I need to install.

I immediately ran into a showstopper bug that they've had for some time now.
Apparently, they've focused on NixOS and the CA certificate configuration is
borked on other platforms. This means Git, Curl and anything else that tries
to use the standard OS certificate store will fail certificate validation. I
know it's only one issue, but it was pernicious enough for me to nuke my Nix
install and move onto something else.

At the moment, the best I can find for OS X is Rudix. The selection of
available software is pathetic compared to Homebrew and Nix, but a lot of the
core stuff is there and it's all packaged as a .pkg, which makes it really
easy to cleanly erase installed software.

~~~
DHowett
> _packaged as a .pkg, which makes it really easy to cleanly erase installed
> software._

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.

~~~
curun1r
Yes, it's not as clean as Nix when it comes to uninstall, but using piping
pkgutil to rm has never gotten my machine in as borked of a state as Homebrew
inevitably does. Also, many .pkg files provide an uninstall script of their
own which is almost always reliable.

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

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

~~~
CJefferson
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.

~~~
davexunit
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.

~~~
CJefferson
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.

~~~
matt4077
well, there's xcode-select to chose the SDK you want which kinda implies the
availability of multiple – currently for example swift 2.2 and 3.0.

I'm tempted by the "1-environment" idea but homebrew has done such an
excellent job in comparison to fink/port, I';; stay loyal. Also wondering if
those two projects couldn't profit from some code sharing?

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

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

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

~~~
bobbyi_settv
> It _uninstall vim_ and install emacs.

If a package system is well designed, having the package for vim on my system
shouldn't be doing any harm even if I'm not currently using it, so the system
you are describing isn't really any better than just having a list of packages
I want installed in a text file.

~~~
sirn
That is not the point I want to make. Having both Vim and Emacs doesn't really
do any harm. You can even have multiple versions of Vim in the same machine,
even with different and incompatible dependency version, and Nix will happily
manage that. The point is that with Nix collection, it will try to build the
system _exactly as described_ without any kind of side effect.

Using Vim isn't the best example (why would someone want multiple Vim?) but
the same apply to languages as well. For example if I want to use Python 3.2,
but there are handful of utilities that require 3.3+. I can just install 3.2
to my profile and install those utilities with 3.5 without actually exposing
3.5 to my profile.

------
aeosynth
Nix is not great for casual Linux desktop usage - I tried installing the Atom
editor, and cancelled when I saw X11 being downloaded. You might as well run
NixOS in a VM.

~~~
ramblenode
It's hard to say what caused this without more information, but the flip side
is that it demonstrates the power of Nix. Everything required to get Atom
working--all the way down to something as basic as the display server--is
explicitly declared in the configuration and can be downloaded and installed
with one command. So although this wasn't what you intended, Nix was actually
doing what it is supposed to do: acquire every necessary component (as per the
specification) for your application to work.

~~~
electroly
This is true, literally, of every package manager that came before Nix and
every one that will come after. It's fundamentally what a package manager is
and does. This isn't the power of Nix -- it's table stakes.

------
nixos
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

~~~
vertex-four
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.

------
res0nat0r
Nix looks cool on OSX, but trying to install something like elixir from
scratch involves my macbook air compiling packages for at least 40+ minutes
before I ctrl-break which is a no go.

I thought Gentoo was cool in the early 2000s when I didn't do sysadmin work
for my job. I'm not waiting an hour or two to install a package anymore.

I'm sure this will improve when more precompiled packages are released for OSX
when it is more popular.

~~~
aidenn0
My understanding is this is at least partly because of a lack of mac build
machines for hydra.

