
Nix as OS X Package Manager - ingve
http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager.html
======
rdtsc
When I first heard about Docker, I thought it did what Nix does.

Then someone handed me a docker image saying, "I got this working on my
laptop, deploy this. Isn't this great!". I had no idea how they arrived at
that configuration. If something happened to them or that image, I wouldn't
have known how to reproduce that "working state".

So I am happy to see Nix / Guix become popular. It is what I imagined package
management to be.

Before that we just used rpm and deb packages. For all the hate they get, they
are actually well thought out, tested, stable format. With
{pre/post}-{install/uninstall} script support, dependency resolution and so
on.

But Nix / Guix is a qualitatively different things. Hope it becomes popular.

~~~
colemickens
I mean, that's exactly what a Dockerfile is for. I don't know of anyone
seriously using Docker that isn't using Dockerfiles exclusively. I only know
of a single time when it's valuable to "commit" a new image (recovering logs
from a stopped container).

None of which is to detract from Nix. Nix+Docker is a powerful combination. It
takes Docker's declarative nature all the way down to the compiler used to
build the bits placed in the container.

~~~
benley
The big difference is that nothing about Dockerfiles implies that the
processes they perform to build an image are deterministic or repeatable. Will
a build step that runs `curl
[https://github.com/something/whatever`](https://github.com/something/whatever`)
do the same thing in six months that it does today? Docker doesn't help with
that at all. Nix improves determinism by (almost) guaranteeing that if you
build the same nix expression six months from now, you'll get exactly the same
dependencies, all the way down to glibc. Either that or the build will just
fail, if remote dependencies aren't downloadable anymore, which is always tons
of fun.

~~~
thejosh
YES.

Finally someone understands what really annoys me when I say that docker isn't
100% reproducible if you aren't using version pinning or something similar.

If you have 2 developers, and one of them does a build the next day, you could
have them with two different versions of a package when the version went up.

~~~
mgkimsal
sounds like 'emerge hell' from gentoo 12 years ago.

~~~
wmertens
Ex-Gentoo dev here. It is not the same. Gentoo emerge runs in place, and you
can definitely break your system with a broken build.

NixOS on the other hand, builds everything in sandboxes that only expose the
requested dependencies. Builds are almost 100% deterministic. The cherry on
top is that your system installation is simply a package consisting of all
other packages and configuration symlinked together, and you replace your
entire system in one go (atomically, by writing a symlink).

If the build fails at any point along the chain, you get an error and your
system remains unchanged. You can totally switch from one major release to the
next (and back) without hassle.

~~~
mgkimsal
the non-deterministic nature is what I was getting at.

I worked at a place where they'd spin up a new gentoo box for a dev with stock
"emerge foo" and let everything run up.

Then 3 weeks later, they'd do it again for the next dev, and they'd have many
diff versions.

I know they weren't "doing it right", but they were doing it the default way
they learned, and it caused a lot of problems.

Thanks for the info/clarification though.

~~~
darkarmani
It's been a LONG time, but when you build gentoo packages you can save the
builds, right? Then if you bring up identical servers, you can just install
from precompiled packages.

------
hso1
Since I discovered Nix, I've been using it as a package manager for OS X and
Linux. Every project my team is working on now has a default.nix file. Getting
started on a project is so easy for a new hire now: just one `nix-env` away
from a fully working dev environment! :D

~~~
drdaeman
By chance, do you have some public/sample projects that use this approach?

~~~
hso1
Yes! Look here: [https://git.hso.rocks/hso/def](https://git.hso.rocks/hso/def)

Is a Telegram bot that queries the RAE dictionary (Spanish). It doesn't have
any documentation yet, though :S

You can look for the project deps code here:
[https://git.hso.rocks/hso](https://git.hso.rocks/hso)

~~~
drdaeman
Looks great, thanks for sharing! I'd definitely try this approach.

Do you write default.nix files by hand, or there are some tools to automate
the process?

I suppose for a project with a lot of dependencies (one of my current
requirements.txt is over 100 SLOC long - almost all deps are on PyPI; haven't
checked nixpkgs as I'm stuck with Debian at the moment) it would be somewhat
tiresome to check every package and for every missing one list all the
dependencies.

~~~
rokgarbas
give pypi2nix a try and ping me on irc if it fails (nick: garbas)

[https://github.com/garbas/pypi2nix](https://github.com/garbas/pypi2nix)

------
j1vms
Could someone post (or link to) the history of Nix, the package manager? Who
developed it, key project milestones, etc.? I understand it comes from, or led
to, NixOS Linux distribution which uses Nix of course.

The nixos.org website is a bit sparse on the Nix project's history, and same
with wikipedia (though separately mentions that NixOS was a research project
started by Eelco Dolstra in 2003).

~~~
tvon
I don't know if it's useful to you, but I can link you to Eelco Dolstra’s PhD
Thesis (2006):

[http://nixos.org/~eelco/pubs/phd-
thesis.pdf](http://nixos.org/~eelco/pubs/phd-thesis.pdf)

He also wrote this InfoQ article on the subject of Nix and NixOS which may
have some useful information (2014):

[https://www.infoq.com/articles/configuration-management-
with...](https://www.infoq.com/articles/configuration-management-with-nix)

The Wikipedia pages for Nix and NixOS also have some interesting references.

[https://en.wikipedia.org/wiki/NixOS](https://en.wikipedia.org/wiki/NixOS)

[https://en.wikipedia.org/wiki/Nix_package_manager](https://en.wikipedia.org/wiki/Nix_package_manager)

Edit: I have been playing with NixOS at home for a few months and I think it's
_very_ interesting, but I'm a bit surprised I haven't heard more about it over
the past decade or so. I'm thinking that the recent industry focus on
deployments and provisioning has caused more people to come across it.

~~~
jf
Thanks for posting these links. I didn't know about the PhD thesis and the
InfoQ article is the best introduction to Nix that I've read yet!

------
AceJohnny2
I was forcefully relocated from my comfortable decade-old Debian home into OS
X, and the package management here in unsatisfying.

I'm looking forward to future posts that show how Nix is better than Homebrew
or MacPorts, because that hasn't been demonstrated so far.

And as a bikeshed nitpick, I was always unhappy with the meaningless rpm
options, preferring apt's clearer options (rpm -qa vs aptitude search). I'm a
bit disappointed that nix chose to mimic rpm's style. Oh well,
tomayto/tomahto.

~~~
SwellJoe
_" I'm looking forward to future posts that show how Nix is better than
Homebrew or MacPorts, because that hasn't been demonstrated so far."_

Homebrew is downright dangerous (I've written about why:
[http://inthebox.webmin.com/homebrew-package-installation-
for...](http://inthebox.webmin.com/homebrew-package-installation-for-servers)
).

MacPorts is fine. Not wonderful, but OK. Not reproducible in the way Nix is.

PkgSrc is also pretty good. Also not reproducible the way Nix is. But, the
packaging policies are good, the packages tend to be well-thought out, and the
technical solution to stuff like dependency resolution is pretty OK. The
people building and maintaining PkgSrc know what they're doing.

Nix is clearly superior to all of them, however, in being reproducible, easy
to roll-back in a predictable way (try going backward with almost any other
package manager, even RPM/yum and dpkg/apt can't do that...I love'em both, but
recognize that we now have better solutions to package management). Nix is
just a fundamentally better tool.

Flatpak is another really promising packaging technology with some of the same
benefits (but it's tackling things in a different way; I think I still have to
consider Nix a better overall solution; it is certainly simpler in both
implementation and usage, for packagers/developers and end users).

But, don't use Homebrew. For now, PkgSrc is probably the best method of
getting a lot of reasonably good packages for Mac OS X. Nix will be the better
option eventually, once there's a lot of people packaging for it (assuming
people get over their bizarre love affair with Homebrew and start working with
Nix, instead).

~~~
eridius
Homebrew is not dangerous. Please don't spread FUD.

Your link specifically covers the case of Homebrew _on the server_. But
Homebrew isn't meant to be a server package manager. It's an OS X package
manager, and OS X is a desktop operating system, not something that most
people choose to use as a server (OS X Server exists but is primarily used for
intranet stuff rather than as a production server). The complaints that your
link has are only problems for an external-facing server. They're not problems
for desktop use. And the simple answer to that is: don't use a desktop package
manager on your server.

~~~
ghshephard
Totally agreed. Homebrew is not an appropriate tool for server package
management (It assumes everything should be installed under a single user
account)- but 98-99%+ of the people that use OS X and servers are not running
OS X on their servers, macmini colo users excepted.

The wording _dangerous_ was poorly used, _inappropriate for server package
management_ would have been better.

~~~
mikemcquaid
"inappropriate for server package management" is totally fair. That's why we
try to generally default to only listening on localhost.

------
JonnieCache
I recently set up a new server for a toy project with nixos and it was a
pleasurable experience, even if I did have to pull together several sources of
somewhat thin documentation. Recommended. Next time I set up a new dev machine
I'm going to give nix a try for dev environment management.

Using nixops to push a closure from your local system up to ec2 is very
pleasing. It feels like the future.

~~~
_query
NixOS is pretty awesome :) For anyone trying to start with NixOS, I suggest
trying it out on a small DigitalOcean server. Check out this[0] blog post on
some hints how to install NixOS there.

A big help is IMO to get a solid understanding about how nix itself works[1].
Also check out some existing `configuration.nix` files on GitHub. Just google
for "github configuration.nix". This might give you some inspiration what you
can do with the `configuration.nix`.

If you have some trouble with customizing vim on NixOS/via nix, checkout
this[2] blog post I wrote a month ago. Hope it helps :)

[0] [http://blog.tinco.nl/2016/02/05/nixos-on-digital-
ocean.html](http://blog.tinco.nl/2016/02/05/nixos-on-digital-ocean.html) [1]
[https://nixos.org/nix/about.html](https://nixos.org/nix/about.html) [2]
[https://www.mpscholten.de/nixos/2016/04/11/setting-up-vim-
on...](https://www.mpscholten.de/nixos/2016/04/11/setting-up-vim-on-
nixos.html)

~~~
lgas
Is there a reason you suggest trying it on DO instead of a local VM?

------
jd3
Why use nix when pkg-src has been available on Darwin for over 15 years,
boasts more packages, and has decades of support (plus Jonathan Perkin and the
guys over at Joyent)? Why people assume the gross project known as homebrew
(and the better macports, where homebrew gets all of their real package
patches) are the only two package managers on OS X/Darwin is perplexing to
me... Not to say nix is not interesting, but still. The OS X open
source/package community would be insanely better if it was solely centralized
around pkg-src.

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

[http://github.com/cmacrae/saveosx](http://github.com/cmacrae/saveosx)

~~~
CJefferson
Hmm.. I've never tried pkg-src before. I'll give it a try.

Step 1: I have to download a gig of stuff before I can install any packages?
Even though my drive is big nowadays, that still seems like a bit of a
waste...

Step 2: Let's try building a package, the last thing I installed with
homebrew.

    
    
        > cd math/minisat
        > make install clean
        Makefile:27: *** missing separator.  Stop.
        > make
        Makefile:27: *** missing separator.  Stop.
    

Hmm.. this isn't the most user-friendly system...

UPDATE: I have to use the bmake I bootstrapped, didn't realise (and the quick-
start docs didn't mention it). Now building begins, but the executable doesn't
link.

~~~
jd3
use the `pkgin` binary to install binaries built from joyent...
([https://pkgsrc.joyent.com/packages/Darwin/](https://pkgsrc.joyent.com/packages/Darwin/))
No need to clone the package tree. This fixes step 1. `sudo bmake install
clean` fixes step two.... (opt needs superuser permissions). see the joyent
link in particular to see how easy it is to install pre-compiled binary
packages with pkgin

------
schneidmaster
Anyone who's used Nix for a while -- how does package availability compare to
Homebrew or Macports? Other than the default.nix thing (which Homebrew also
has a version of [1]) are there any other clear benefits to switching from
Homebrew?

[1]: [https://robots.thoughtbot.com/brewfile-a-gemfile-but-for-
hom...](https://robots.thoughtbot.com/brewfile-a-gemfile-but-for-homebrew)

~~~
sirn
The last time I tried (a month ago), I could reproduce _most_ of my current
Homebrew packages. There are few that are broken (e.g. rust, which has since
been fixed), or do not have Darwin support (aria2c, which I have a PR
open[1]). There are also packages that are a little bit hard to discover, e.g.
those that are imported from Haskell's Hackage where it is not listed by
default[2] when you do `nix-env -i <packageName>` (e.g. shellcheck).

From my few days of trying to replace Homebrew with Nix, being able to
rollback the environment to last known good state (`nix-env --rollback`),
ability to keep track of package changes (`nix-env --list-generations`),
ability to try a package without installing it (`nix-shell`, well, technically
it's installed on the machine, but nothing is linked in the profile, and you
can nuke them with `nix-collect-garbage`) are very nice additions.

Apart from these features, the fact that it doesn't chown `/usr/local/` to my
user is a big plus. Nix will also _not_ linking anything not explicitly
installed by user to their profile (e.g. if package A has B as dependency, B
won't be linked until user actually choose to install it, which is then
managed separately from B that were explicitly installed as A's dependency).

That said, I've since revert back to Homebrew because there are few packages
broken that are crucial to what I'm working on. Creating and fixing package is
not too hard (I did with aria2c), although time didn't allow me to do it back
then. I would love to try to switch to Nix again sometimes.

People in ##nix-darwin are super-nice, also! :-)

[1]:
[https://github.com/NixOS/nixpkgs/pull/15029](https://github.com/NixOS/nixpkgs/pull/15029)

[2]: [https://nixos.org/nixpkgs/manual/#users-guide-to-the-
haskell...](https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-
infrastructure)

~~~
schneidmaster
Thanks for the review. I think I'll definitely have to give it a try next time
I've got a free weekend.

------
xaduha
Nix is impressive, NixOS is more impressive still.

------
arm
It seems like when installing Nix, it needs to create a 'nix' directory in
your root directory. While I haven’t tried installing Nix yet myself, I’m
guessing this probably won’t work on OS X v10.11 El Capitan due to System
Integrity Protection¹. You’ll have to temporarily turn it off² first before
attempting to install Nix (and then optionally turn it back on after).

――――――

¹ — [https://derflounder.wordpress.com/2015/10/01/system-
integrit...](https://derflounder.wordpress.com/2015/10/01/system-integrity-
protection-adding-another-layer-to-apples-security-model/)

² —
[http://www.madrau.com/support/support/srx_1011.html](http://www.madrau.com/support/support/srx_1011.html)

~~~
cstrahan
Ooh, that's an excellent point -- thanks for bringing it up. I've had Nix
installed since early 2014, so I haven't run into any trouble with SIP yet.
Looks like we might need to update our docs, and maybe have the installer give
a helpful tip.

~~~
Watabou
Unless /nix modifies files/folders, then no, you don't need to modify your
install instructions.

SIP only prevents users from _modifying_ system level files. It does not
prevent you from adding to, or deleting your own files within the `/`
directory.

------
cel1ne
Is there any reason to switch if homebrew worked perfectly for me in the last
couple of years?

~~~
guitarbill
none, which is why this article is so vague.

like i needed another folder in root, as if `/opt/`, `/usr/local/` or
`~/.local/share` weren't good enough and this is somehow a feature. another
package manager that has less features than homebrew? oh, like fink and
macports - no thanks.

~~~
cstrahan
It would appear that your primary takeaway is that we put stuff in a different
directory, for an apparently arbitrary reason. I agree, that would be silly --
if it were the case.

With /usr/local/{bin,lib,include}, how would you install multiple versions of
openssl? Would you violate convention and do something like
/usr/local/openssl-x.x.x/{bin,lib,include}? How do you avoid file path
conflicts? When a package is built against a particular version of openssl,
how do you ensure that version of openssl sticks around, and that that, upon
execution of said program, the dynamic linker loads specifically that version
of openssl and not one of the others?

While I encourage you to consider those questions, the short answer is "you
can't". At least, not with conventional package managers like Homebrew.

Because Nix builds each package in a unique prefix (governed by the hash of
all of the build inputs, recursively), the Nix package manager can use chroots
(and Sandboxes on OSX) to ensure that packages are deterministic, and that
each package refers specifically to the versions of the dependencies they need
(dynamic libraries are fixed via rpaths and we apply patches for references to
executables -- so "python -m foo" becomes e.g.
"/nix/store/<HASH>-python-2.7/bin/python -m foo").

If you don't use a unique prefix per package, the problem of "how do I install
stuff without worrying about path collisions amongst the multiple versions of
requisites" becomes intractable. Ditto for build determinism, binary caches,
lightweight environments a la _nix-shell_ , etc.

I suppose we _could_ shoehorn each package into
/usr/local/<HASH>-<NAME>-<VERSION>/{lib,bin,include}, and then we could tick
the "use an existing directory under /" box, but is that really better? I
don't see what we gain from that, since that's already an abuse of /usr/local.

~~~
guitarbill
Thanks for the enlightened response to my rather curt post.

I guess my main issue with the original article was that if you don't already
know what nix is, the benefit is not at all obvious, especially for the
(above?) average joe for whom homebrew works fine. For a sysadmin who is sick
of dependencies breaking, even when using something like aptitude, it sounds
perfect though.

Although after skimming the nix docs [1] and reading your reply, I'm still not
sure why e.g. `/opt/nix/` wouldn't work. Maybe it would, except for the fact
that `/nix` was decided on and if you now change that, the prebuilt packages
break (see [1])? Obviously, it isn't a deal-breaker, but e.g. consider an
existing backup solution which might have been configured inclusive, not
exclusive.

Also, I get that as a package manager, nix is in a different position than
most programs, but putting stuff in `/` isn't a great precedent, and other
package managers don't AFAIK.

[1] [https://nixos.org/nix/manual/#ch-about-
nix](https://nixos.org/nix/manual/#ch-about-nix)

------
justacodefan
Great cliffhanger for the next article at the end.

------
ris
Having set up my last company doing all development and deployment using nix,
moving to a new team which just uses pip/virtualenv and a "bootstrapping
script" feels a little unnerving to start with.

~~~
cttet
Is there any good guides to get started on nix with python?

~~~
ris
The nixpkgs manual has a section on it [https://nixos.org/nixpkgs/manual/#sec-
python](https://nixos.org/nixpkgs/manual/#sec-python) but the key to it is
that it's really mostly about managing your PYTHONPATH. You wouldn't typically
be installing a python package and just expecting it to be available to a
session-launched python invocation (because PYTHONPATH is not exported to the
user env of a profile), instead you would probably use nix-shell or a custom-
built python environment with the exact package setup you desire...

------
yarou
I demoed NixOS a few years back when I was wrangling with the Haskell
ecosystem.

I was pleasantly surprised, as I could rollback the entire state of my system
from GRUB itself if anything went screwy.

------
nickysielicki
> curl [https://nixos.org/nix/install](https://nixos.org/nix/install) | sh

Stop doing this.

Look, even if you are rolling your eyes and thinking, "it's https and I'm not
Ed Snowden, I think I can afford the risk for the benefit of an easy install
process", what happens if curl is interrupted? Are you excited at the prospect
of a half-ran install script that you didn't even look at?

~~~
oconnore
No [1].

If you are installing software from scratch, you _must_ trust the https server
that serves it to you.

They could publish sha256 check sums to
[https://nixos.org/hashes](https://nixos.org/hashes), but you would have to
trust the https server.

They could publish their gpg key to
[https://nixos.org/gpg](https://nixos.org/gpg), but you would have to trust
the https server.

Things would be better if we had a reasonable certificate system for verifying
open source software, but we don't. There is no gpg web of trust. There is no
hierarchical CA system for code signing that open source authors can easily
plug into, and expect their users to verify.

If you care this much, stop astroturfing and go build a system that does
better. It will be very hard work, and you will have to distribute the first
version of your solution with an https server that your users will have to
trust.

[1]: Ok, so maybe the instructions could be "curl <url> -o install.sh && sh
install.sh".

~~~
falcolas
> If you are installing software from scratch, you _must_ trust the https
> server that serves it to you

This is incorrect - you are forced by `curl | sh` to trust all of the 1000+
CAs in your OS' keystore. And if you can't trust all of them (since some have
given out Google certs before, you can't), how can you trust what you're
getting over HTTPS?

With hashes, they are not typically served from the same domain. That's the
_minimum_ level of protection for the user.

Signing with a key is another level of protection; it lets the _user_ (not the
OS) decide the level of trust, and even verify the key with the author of the
package via a completely separate channel.

Now the question really becomes, why _doesn 't_ the provider use the existing
(secure) channels of software distribution? RPMs, DEBs, installer packages for
Macs, MSAs for Windows?

~~~
danpalmer
> you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS'
> keystore. And if you can't trust all of them

If you don't trust them, they should not be in your certificate store. That's
not a problem with using `curl | sh`, it's a problem with the certificate
store and what the user is trusting.

------
sdegutis
What happens when packages need to store data?

For example, installing Datomic via Brew will result in databases being stored
in:

/usr/local/Cellar/datomic/0.9.5206/libexec/data

How would that work with Nix? Would the data live under /nix?

And most importantly, would that data get squashed because of some kind of
idempotency assumptions that Nix might make?

~~~
mapcars
>would that work with Nix?

Yes.

>Would the data live under /nix?

No, Datomic will be built with another default data directory.

>would that data get squashed because of some kind of idempotency assumptions
that Nix might make?

No, since data is stored separately.

------
Razengan
This is amazing. As someone who hates clutter and having to use sudo for
anything, Nix is just what I needed!

------
didip
Is there a way to install packages on user space without proot? Why does it
need /nix?

~~~
aseipp
You can install packages by installing nix into your homedir. But you will
never get binary packages this way.

The reason is because when the software is compiled, it's stashed in the /nix
directory, and might refer to other artifacts in /nix. For example, zlib.so
exists in /nix/store/zlib-.../lib/zlib.so, and links to glibc.so, which exists
in /nix/store/glibc-.../lib/libc.so.6. So if you want to install zlib and get
binary packages, you need to first install glibc. And you need to put glibc in
the place that zlib will expect it.

------
all_usernames
Wait... binaries inside a ~homedir/.dotfile/? Why on earth?

~~~
ricardobeat
I believe those are just symlinks to the binaries in /nix/xxxx, so that
$HOME/.nix/bin can be added to PATH.

------
agumonkey
Only two results about nix on windows, and not very enthusiastic ones. Too
bad.

------
educar
This sounds exactly like what homebrew does. It also installs under /usr/local
and does not touch anything else. What does nix package manager provide that
homebrew does not? (from a user point of view)

~~~
cstrahan
Hi, I'm a NixOS/Nixpkgs comitter and package maintainer for plenty of stuff --
including X11/XQuartz for OSX.

Nope. They both do package management, but that's where the similarities end.

Homebrew packages are not patched to point at precisely the version of the
stuff they were built against. For example, if you have program that
dynamically links to openssl, that program is built with the expectation that
the dynamic linker will be able to find e.g. libssl.dylib in either /usr/lib
or /usr/local/lib (the specifics are harrier, but that's a decent
approximation). If you later upgrade openssl and the ABI changes, you've now
silently broken everything that uses it -- you'll now get a segfault at
runtime (I've had this happen with openssl and many other libs on Homebrew,
and is part of why I was (and still am) very excited about Nix).

When you compile a package with Homebrew, you're not guaranteed to end up with
the same result as someone else, even if they have the same checkout of the
formulae. Why? Well, each project's Makefile (or what have you) will try to
run whatever's on $PATH, and poke around elsewhere on your system to e.g.
automatically enable build flags (oh, luajit is installed? I guess I'll just
go ahead and enable Lua scripting and link to it).

How does that compare with Nix?

Nix packages are patched so that their runtime dependencies (dynamic
libraries, programs to be execed, shebang lines, etc) are locked down to the
precise build that was specified as part of the package. The obvious
implication here is that Nix packages can be trivially installed with
differing versions of dependencies as necessary (back in the day, I wanted to
play with both the Elixir langauge and the Riak DB, but they required two
different major versions of Erlang. Unfortunately, I could only install one
version, as the packages for both versions wanted to be placed in the exact
same prefix and the filenames would overlap. This was on Ubuntu, but it
applies equally to Homebrew).

When compiling a Nix package, I can rest assured that the build artifacts will
be equivalent between two different machines (not bit-for-bit, but at least
functionally equivalent -- excepting compiler bugs). Why? Because the build
happens in an isolated environment where, as far as the build process is
concerned (we take advantage of a number of kernel features on Linux (chroot)
and OSX (Sandboxes)), the system _only_ consists of the packages _explicitly_
listed as build inputs -- nothing else. Excepting esoteric stuff like someone
_intentionally_ trying to subvert chroots and such, if you were to put a gun
to my head and tell me that you were going to shoot me if you could find a
case of non-determism, I'd shrug. We're _serious_ about that whole determinism
thing -- it's a core selling point of Nix, and the reason for Nix's "quirks"
(the per package prefixes, hashing of build inputs, chroots, lack of network
access, etc).

If the above doesn't make the differences obvious, I'll challenge you to
answer some questions (the socratic method):

1\. How does Homebrew support having two versions of openssl installed
concurrently? Describe the paths involved, how the dynamic linker would be
guaranteed to load the respective version of libssl, etc.

2\. How does Homebrew ensure packages are built exactly the same way across
two different machines (e.g. using the same version of autotools, clang, make,
etc)? Be sure to explain how the build is guaranteed to not auto detect/enable
stuff because of things present on my system that may not be present on your
system. Note that Nix will deterministically fail if you fail to explicitly
list all of its dependencies (rather than working because, say, cmake just so
happened to be installed on the formula author's machine) -- so you'll need to
describe how Homebrew achieves this when running a formula.

~~~
educar
Hey, thanks for taking the time for the informative response. I see the
difference now.

~~~
cstrahan
You're very welcome -- thanks for raising the question :)

------
philipsunrise
See you all in five years when Nix is shit and we're all switching to Flurp as
our package manager.

~~~
fucking_tragedy
I ended up searching "Flurp" because with the current state of things, there
was a chance that this was real.

~~~
geggam
Add javascript to the search. Sometimes I do that with random searches just to
see the crazy things people are doing with Javascript

