3 ms·

Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years

Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, javascript) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development.

downerending 6y ago
As an example, what's minimally required to run two different versions of program-x from the command line. Can I do something like this easily? cat-8.22 /etc/passwd | cat-8.3 -A
- abathur 6y ago
  First: It depends on what you mean by "easily" General installs from Nixpkgs aren't going to be highly-idiomatic. You can install two different versions of coreutils, but one of them is still always going to be first on your PATH. So, if you want to specify the version in each command like this, you'll have to override the expressions to write a version number into the name of each binary. (But, yes, they're both on your PATH. If by "easily" you mean you could run `type -a` and pick the correct full path for each and then run them in a pipeline like this--yes.) I guess you could also build the path of each into an environment variable, or maybe create a wrapper for each with the version name included. Second: This is an awkward example because people rarely use multiple versions of coreutils concurrently, so there's just one version at a time in a current version of Nixpkgs. It'd be easy to put more than one python or ruby or postgresql in the same expression--things people are more likely to need (and thus multiple recent versions are all available at once)--but you'll (probably) have to work a little harder to do something like coreutils. (i.e., copy in a complete expression for each, or pull each version from two different commits in Nixpkgs. Nix makes it fairly simple to override an existing expression to change something like the version/commit used, but it breaks down if there are substantive changes in what's required to build them. Given the nearly 4 years between the early 2010 release of 8.3 and the late 2013 release of 8.22, I'd be surprised if they'll build with the same expression.
- tomberek 6y ago
  Minimal example: export v824=$(nix-build 'channel:nixos-15.09-small' -A coreutils) export v830=$(nix-build 'channel:nixos-19.09-small' -A coreutils) $v824/bin/cat /etc/passwd | $v830/bin/cat -A You can get better specificity by using a nixpkgs git repo/hash instead of channel or adding `--no-out-link`, but this is minimal.
  - Shoue 6y ago
    Even more concise: nix run -f channel:nixos-19.03 hello -c hello | nix run -f channel:nixos-20.03 ripgrep -c rg Hello
- takeda 6y ago
  tomberek gave you example how to do it, although I think in real life you probably won't need to do something like this. Much more common situation is having two programs that depend on conflicting version of a library. You get this often if you start including custom repos into your system, because you need specific version of something. Sometimes you make that application work, but then you break something else. Docker is often pitched to solve this, you get one application in one docker, and another in another. Since docker isolates and pretends to have 2 different operating systems it kind of allows this to happen, but that's hacky. Nix solves this correctly. Instead of having some central place listing what libraries are installed on the system, it actually every component listed in an unique path. This way application A can use library X and application B can use library Y even when X and Y are different versions of the same library. What's more, is that the derivations in nix can be extended like objects in OO class. You can easily modify application A to use library Y and B to use library X. And if such build is not available in cache Nix will know how to rebuild it (no need to worry about having compiler and libraries installed).
  - downerending 6y ago
    Yes, that's probably the more typical case. Thanks!

downerending 6y ago

As an example, what's minimally required to run two different versions of program-x from the command line. Can I do something like this easily? cat-8.22 /etc/passwd | cat-8.3 -A

abathur 6y ago
First: It depends on what you mean by "easily" General installs from Nixpkgs aren't going to be highly-idiomatic. You can install two different versions of coreutils, but one of them is still always going to be first on your PATH. So, if you want to specify the version in each command like this, you'll have to override the expressions to write a version number into the name of each binary. (But, yes, they're both on your PATH. If by "easily" you mean you could run `type -a` and pick the correct full path for each and then run them in a pipeline like this--yes.) I guess you could also build the path of each into an environment variable, or maybe create a wrapper for each with the version name included. Second: This is an awkward example because people rarely use multiple versions of coreutils concurrently, so there's just one version at a time in a current version of Nixpkgs. It'd be easy to put more than one python or ruby or postgresql in the same expression--things people are more likely to need (and thus multiple recent versions are all available at once)--but you'll (probably) have to work a little harder to do something like coreutils. (i.e., copy in a complete expression for each, or pull each version from two different commits in Nixpkgs. Nix makes it fairly simple to override an existing expression to change something like the version/commit used, but it breaks down if there are substantive changes in what's required to build them. Given the nearly 4 years between the early 2010 release of 8.3 and the late 2013 release of 8.22, I'd be surprised if they'll build with the same expression.
tomberek 6y ago
Minimal example: export v824=$(nix-build 'channel:nixos-15.09-small' -A coreutils) export v830=$(nix-build 'channel:nixos-19.09-small' -A coreutils) $v824/bin/cat /etc/passwd | $v830/bin/cat -A You can get better specificity by using a nixpkgs git repo/hash instead of channel or adding `--no-out-link`, but this is minimal.
- Shoue 6y ago
  Even more concise: nix run -f channel:nixos-19.03 hello -c hello | nix run -f channel:nixos-20.03 ripgrep -c rg Hello
takeda 6y ago
tomberek gave you example how to do it, although I think in real life you probably won't need to do something like this. Much more common situation is having two programs that depend on conflicting version of a library. You get this often if you start including custom repos into your system, because you need specific version of something. Sometimes you make that application work, but then you break something else. Docker is often pitched to solve this, you get one application in one docker, and another in another. Since docker isolates and pretends to have 2 different operating systems it kind of allows this to happen, but that's hacky. Nix solves this correctly. Instead of having some central place listing what libraries are installed on the system, it actually every component listed in an unique path. This way application A can use library X and application B can use library Y even when X and Y are different versions of the same library. What's more, is that the derivations in nix can be extended like objects in OO class. You can easily modify application A to use library Y and B to use library X. And if such build is not available in cache Nix will know how to rebuild it (no need to worry about having compiler and libraries installed).
- downerending 6y ago
  Yes, that's probably the more typical case. Thanks!