Hacker News Reader

Comment by mguijarr | Hacker News Reader

How does Nix compare with conda[0] ? I could not find any useful resource, in my team we were hesitating between the two, for packages management ; finally we went for conda because it (seems)is better documented and package description is easier to write for newbies. And also we are a Python shop, so other devs felt more comfortable with conda. Personally I prefer Nix, though, and I wanted to advocate for it but the only main difference I could find is that Nix sits on top of the kernel (including libc...) whereas conda uses the system libc.

[0]: https://conda.io

View on HN

I wrote this document: http://catern.com/posts/deps.html which briefly compares both Conda and Nix among other things.

(warning: it's very pro-Nix :) )

You claim that conda "isn't very well supported by Unix as a whole" and "doesn't really work." Can you provide some evidence or examples to back up your claim?

Sorry, I guess it basically requires you already know the ways in which Conda doesn't work. The basic problem is that Unix has a lot of hardcoded paths and no way to override them all at runtime. So you need to do lots of patching and hacks.

That is excellent, thanks. Double for mentioning Docker.

Not to put down Nix, but some of the arguments about other systems have counterexamples. For instance, it's common in rpm or dpkg distributions to have multiple versions and implementations of things, and richer dependencies than simply on packages. You can also do unprivileged installation into a separate root with, say, fakechroot or PRoot, and you need something like that to install and run Nix unprivileged, don't you?

There are comparisons with alternatives in at least the propaganda for Spack and 0install, though the same criticism might apply to those -- I don't remember.

rpm and dpkg don't support having multiple versions and implementations of things simultaneously installed. Not sure what you mean by richer dependencies.

>You can also do unprivileged installation into a separate root with, say, fakechroot or PRoot

Yes, but that's the only way to (safely) use such package managers without privileges; so that's not viable to do for production.

>and you need something like that to install and run Nix unprivileged, don't you?

Install, yes. Run, no. Setting up Nix does require root, but once it's installed on a system it can be safely used without privileges by all the users on the system. That's very valuable in itself, but it's especially interesting when you consider providing access to a single Nix store over a network filesystem, or providing it to multiple different virtual machines or containers.

On RHEL 6 I count eight different packages implementing the MPI standard -- multiple versions of three implementations of essentially the same API -- which can be installed together. The richness is that dependencies are not generally simply on packages; MPI packages provide things like "mpi", "openmpi(x86-64) = 1.10.3-3.el7", "libmpi.so.12", and config(openmpi) = 1.10.3-3.el7".

My Guix installation runs using a with privileged access to the store, and Nix is the same as far as I know. I don't know why Nix would be a particular advantage on our HPC networked filesystems, and it's not clear it's tenable for users to be able to DoS the store by installing an arbitrary amount of software in limited shared space.

It may well be that Nix makes the right set of trades-off against other possibilities for a given situation, but thta seems at least not completely clear cut.

You can install Nix in a totally unprivileged fashion, without having to use hacks such as PRoot, you just need to configure it to use a directory you have write access to instead of /nix. But doing so breaks the ability to use the official binary caches (because relocating the store requires recompiling packages), and this isn't particular to nix (I remember that portage at least does this too, and probably some others). The interesting part is that with an installed deamon, the admin can allow users to install packages in their own profile, while still benefiting from sharing of dependencies and other niceties.

About the multiple versions, the problem with "classical" package managers is that you have to do some manual renaming to ensure that both versions won't be installed in the same place in the file-system, which is tedious and doesn't scale well. Furthermore you may encounter some problems because both will be visible at the same time if the packager isn't careful enough. For example, if a software X has a dependency of libfoo2.1 and you happen to have libfoo3.1 also installed, the installation script for X may use libfoo3.1 instead of libfoo2.1, in which case you risk to encounter bugs because X hasn't been tested against libfoo3.1.

I use conda every day in my professional deep learning practice and it's a HUGE time saver. I can't press enough how I'm sure it's already saved me weeks if not months of package butfucking.

Reply on news.ycombinator.com