3 ms·

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 home

by educar 10y ago

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)

zachrose 10y ago
Nix groups all of your installed packages in one environment. When you install a new package, it creates a new environment with the new package added to it. This alone may sound insignificant, but it enables having multiple nix environments (e.g. one per project) and switching between them very quickly and easily.
- educar 10y ago
  Can you give me an example of projects which require this setup? (Even a personal anecdote will do)
  - mikeho1999 10y ago
    I've never heard of nix, so I can't comment to that specifically. But being able to have multiple / separated environments on my machine would be hugely beneficial. Working for a full-time software consulting agency, I'm normally actively working on many projects at the same time, each of which have their own nuances of packages that are required (e.g. different versions of PHP, different sets of dependencies, etc.) So if nix truly offers seamless switching between environments (and if it can do it quickly and efficiently), it would definitely be worth it for me to look into it further.
    - Ericson2314 10y ago
      It utterly does!
  - educar 10y ago
    Can't reply to sibling post for whatever reason. > Working for a full-time software consulting agency, I'm normally actively working on many projects at the same time, each of which have their own nuances of packages that are required (e.g. different versions of PHP, different sets of dependencies, etc.) I don't think this is what Nix offers. This is more like a homebrew competitor (I assume you don't use homebrew to install php...).
    - swsieber 10y ago
      According to zachrose though (GP) it's exactly what it's supposed to do. See also this comment (great uncle post?) https://news.ycombinator.com/item?id=11773206 https://news.ycombinator.com/item?id=11773206 It talks about being able to setup and instance of emacs referencing a specific nix environment. Edit: This comment also talks about using it to solve virtualenv shortcomings. https://news.ycombinator.com/item?id=11773036 https://news.ycombinator.com/item?id=11773036
    - cstrahan 10y ago
      Yes, this is what Nix offers. You can trivially have have multiple versions of stuff installed without conflicts. Personally, I have multiple versions of the GHC Haskell compiler, Clang/LLVM, Go, Node, etc. In fact, I keep shell.nix file in each of my repositories at work, and all I have to do is $ nix-shell in each project root and -- like magic -- I have all of the compilers/environment-variables/etc setup for work. Meanwhile, outside of that terminal window, my system is untouched. Nix is quite different from just about any other package manager out there. If there's something that seems unfeasible or impossible, please feel free to ask specific questions to challenge my assertions. Nix is so different that it will be tempting to think "surely he means... no, that can't be possible, he must be mistaken... but how would that work?" Rather than silently thinking those things, please feel free to skip right to asking "how?" (For more details, see also my long post to your original statement/question)
  - RubenSandwich 10y ago
    Here is a personal anecdote: Managing multiple versions of openCV on OS X. OpenCV has a long laundry list of dependencies and trying to get two versions to build can be a nightmare. (It's much easier to just update one of your projects to use the same version of OpenCV as the other one.) With Nix each of those OpenCV versions can live completely isolated from each other so their dynamically linked dependencies don't get overridden by each other.
cstrahan 10y ago
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.

by educar 10y ago

zachrose 10y ago

Nix groups all of your installed packages in one environment. When you install a new package, it creates a new environment with the new package added to it. This alone may sound insignificant, but it enables having multiple nix environments (e.g. one per project) and switching between them very quickly and easily.

educar 10y ago
Can you give me an example of projects which require this setup? (Even a personal anecdote will do)
- mikeho1999 10y ago
  I've never heard of nix, so I can't comment to that specifically. But being able to have multiple / separated environments on my machine would be hugely beneficial. Working for a full-time software consulting agency, I'm normally actively working on many projects at the same time, each of which have their own nuances of packages that are required (e.g. different versions of PHP, different sets of dependencies, etc.) So if nix truly offers seamless switching between environments (and if it can do it quickly and efficiently), it would definitely be worth it for me to look into it further.
  - Ericson2314 10y ago
    It utterly does!
- educar 10y ago
  Can't reply to sibling post for whatever reason. > Working for a full-time software consulting agency, I'm normally actively working on many projects at the same time, each of which have their own nuances of packages that are required (e.g. different versions of PHP, different sets of dependencies, etc.) I don't think this is what Nix offers. This is more like a homebrew competitor (I assume you don't use homebrew to install php...).
  - swsieber 10y ago
    According to zachrose though (GP) it's exactly what it's supposed to do. See also this comment (great uncle post?) https://news.ycombinator.com/item?id=11773206 https://news.ycombinator.com/item?id=11773206 It talks about being able to setup and instance of emacs referencing a specific nix environment. Edit: This comment also talks about using it to solve virtualenv shortcomings. https://news.ycombinator.com/item?id=11773036 https://news.ycombinator.com/item?id=11773036
  - cstrahan 10y ago
    Yes, this is what Nix offers. You can trivially have have multiple versions of stuff installed without conflicts. Personally, I have multiple versions of the GHC Haskell compiler, Clang/LLVM, Go, Node, etc. In fact, I keep shell.nix file in each of my repositories at work, and all I have to do is $ nix-shell in each project root and -- like magic -- I have all of the compilers/environment-variables/etc setup for work. Meanwhile, outside of that terminal window, my system is untouched. Nix is quite different from just about any other package manager out there. If there's something that seems unfeasible or impossible, please feel free to ask specific questions to challenge my assertions. Nix is so different that it will be tempting to think "surely he means... no, that can't be possible, he must be mistaken... but how would that work?" Rather than silently thinking those things, please feel free to skip right to asking "how?" (For more details, see also my long post to your original statement/question)
- RubenSandwich 10y ago
  Here is a personal anecdote: Managing multiple versions of openCV on OS X. OpenCV has a long laundry list of dependencies and trying to get two versions to build can be a nightmare. (It's much easier to just update one of your projects to use the same version of OpenCV as the other one.) With Nix each of those OpenCV versions can live completely isolated from each other so their dynamically linked dependencies don't get overridden by each other.

cstrahan 10y ago

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.