8 ms·

First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. Second, to use this package manager, you first need to insta

First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. Second, to use this package manager, you first need to install direnv. How do you install it? with brew, a different package manager. Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first. Fourth, finally, we get to install a simple Unix program, that any package manager could have provided. For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. "Reproducibility!" Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic. And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That's only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers. Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don't need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else.

rossmohax 5y ago
It's not about what is possible, it is about ergonomics. We could have used email for conversations online, yet we use Slack. Other tool require lots of thought and carefull execution for what Nix gives you for free.
- dmitriid 5y ago
  > Other tool require lots of thought and carefull execution for what Nix gives you for free. How do I pin ruby version to 2.6.3 in Nix? This is given to me for free in other tools. As are reproducible builds because all modern package/dependency managers lock versions.
  - rossmohax 5y ago
    It is not the same level of reproducibility like Nix and Bazel provides. You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays
    - dmitriid 5y ago
      > It is not the same level of reproducibility like Nix and Bazel provides. What is "the same level"? > You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays That page says: "Overlays provide a method to extend and change nixpkgs" I don't want to change something. I want to simply pin a version. This is neither simple, nor scalable, nor maintainable (also here: https://news.ycombinator.com/item?id=28591202 https://news.ycombinator.com/item?id=28591202): Overriding a version self: super: { sl = super.sl.overrideAttrs (old: { src = super.fetchFromGitHub { owner = "mtoyoda"; repo = "sl"; rev = "923e7d7ebc5c1f009755bdeb789ac25658ccce03"; # If you don't know the hash, the first time, set: # sha256 = "0000000000000000000000000000000000000000000000000000"; # then nix will fail the build with such an error message: # hash mismatch in fixed-output derivation '/nix/store/m1ga09c0z1a6n7rj8ky3s31dpgalsn0n-source': # wanted: sha256:0000000000000000000000000000000000000000000000000000 # got: sha256:173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4 sha256 = "173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4"; }; }); }
      - rvanlaar 5y ago
        Reading your linked post, it seems you are wrestling with how Nix works. Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do. As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?
        dmitriid 5y ago
        > Reading your linked post, it seems you are wrestling with how Nix works. Not only me. > That's because it's solving slightly different problems than package managers currently do. We keep hearing this claim, and hardly any proof of that. > As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable? 1. Commit hashes are not versions 2. Hunting down every commit hash of every package to pin down the exact version is neither maintainable nor scalable
Arkh4m 5y ago
First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to reload your shell. Most current version managers either do it themselves through shell hooks or ask you to install direnv. Point taken on using brew: I've changed it to use nix-env. Third. Yep. Sort of like having to learn English before you can learn programming. Fourth. As they say: start with the basics. Fifth. No other package manager can freeze the complete dependency set you are using AND allow you to revert it exactly when things don't work. That's the power of declarative, reproducible builds: you try to update and it doesn't work? No problem, revert to the last working version and things are all good again. Sixth. Ever tried updating a project using a Dockerfile that uses an old version of ubuntu? Then you can't find the packages anymore or no is building them anymore for the new version of Ubuntu and you have to pull random PPAs from the Internet to get things to work? In Nix, you can keep two pinned nixpkgs versions at the same time. In this way you can keep working on upgrading your project one working step at the time. So yeah, it's not just cHeCKmATe FP-atheists sort of stuff.
- throwaway984393 5y ago
  For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them after they're built the first time in an artifact repository. Any builds of your app that use a container need to be versioned to prove they've been tested successfully, anyway, and you want to keep them around to do fast rollbacks without having to kick off a build just to roll back. So you don't need reproducibility for reliability. It's mostly used for security: build on two siloed systems, compare the results. Version-pinning in general is to prevent silent upgrades that break your builds. But you also don't want to version-pin everything, as you want security patches to get automatically applied with regularly-recurring builds. So in practice, you stick with a major branch of something, silently accept upgraded packages or minor version bumps, and have an automated system flag if you aren't running the latest security packages. All of that works fine with Docker and Apt. More often than breakage due to silent upgrade is the security patch problem, where somebody pinned to a version 4 years ago and has never patched, and it's been so long that all the downstream effects of patching force you to do an entire lift-and-shift to new everything. Gradual continuous updates (stick to a major version, run tests) is the best middle ground. Modern projects with Docker containers have standardized their tagging around this.
GoblinSlayer 5y ago
Imagine having a whole language, but still running shell scripts to create folders and replace text. I mean even rpm can create folders declaratively.
takeda 5y ago
> First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. This is not true. The defining point about Nix is that it allows to define all dependencies explicitly. Every derivation in it is built inside of a sandbox with no access to network and restricted filesystem. This ensures that nothing is accidentally missed. Package management is just one of features. > Second, to use this package manager, you first need to install direnv. How do you install it? with brew, a different package manager. direnv is not needed to use Nix, it's just a nice add-on. It's like you don't need Ranger to navigate in a file system, but it is nice. Besides, you can install direnv through nix, I use it this way. Even nix is installed by itself as well. > Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first. Well, yes you do, but language is actually quite simple it's the nixpkgs (repo containing all packages) that's quite complex. Nix's purely functional, lazily evaluated properties exactly fit as a language describing dependencies. > Fourth, finally, we get to install a simple Unix program, that any package manager could have provided. If you were trying to install a package, you don't need to learn anything, you just install it (for example to install ranger you just run nix-env -iA nixpkgs.ranger). Nix language is only needed if you want to create a new package. > For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. "Reproducibility!" Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic. > And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That's only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers. > Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don't need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. Nix delivers what docker promised and ultimately failed to deliver. Docker promised to reproduce developer's environment to production. What it did was to zip developer's computer and deploy it. When docker got adopted, relying on images was impractical, so for deployment Dockerfile was used, but that file is not much different than a shell script. Nix instead describes the entire dependency tree down to libc. Because the starting state and all dependencies are known it can always create the same result, that's the biggest selling point of Nix to me.
globular-toast 5y ago
> Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. As a Gentoo user and someone who has tried and grokked Nix/Guix, this is not true at all. Gentoo is essentially a system for creating distributions, a meta-distro if you like. It just so happens to be something that appeals to someone like me to run at home because, well, why not? I know exactly what I need/want on my computer and this lets me build my own custom distro tailored for me. Nix/Guix is something completely different. It addresses real problems that arise in a variety of places in an elegant way. Containers are another solution to some of these problems, but come with their own tradeoffs. Your blanket statement about "professionals" makes no sense. I don't use Gentoo at work because it's not my job to maintain custom Linux systems or create distros. But guess what? Not everyone has the same job. You don't speak for all "professionals". I can distinctly remember around 2007 people saying this exact thing about git. I was told geeks were only learning it to make themselves feel clever and that SVN was fine. Well look how that turned out. I'm glad I ignored those people.
shantnutiwari 5y ago
I've heard about nix here often, but everytime they show toy examples. And if you want to do anything complicated, it's all get this hash, use this trick, this extra tool etc etc. At which point, it's just easier to stick with what you have. >> a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. yeah, getting the same vibe. Lots of hype not backed by any evidence. For me, to start off, I'd like to see a real example, not some made up simple use case

rossmohax 5y ago

It's not about what is possible, it is about ergonomics. We could have used email for conversations online, yet we use Slack. Other tool require lots of thought and carefull execution for what Nix gives you for free.

dmitriid 5y ago
> Other tool require lots of thought and carefull execution for what Nix gives you for free. How do I pin ruby version to 2.6.3 in Nix? This is given to me for free in other tools. As are reproducible builds because all modern package/dependency managers lock versions.
- rossmohax 5y ago
  It is not the same level of reproducibility like Nix and Bazel provides. You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays
  - dmitriid 5y ago
    > It is not the same level of reproducibility like Nix and Bazel provides. What is "the same level"? > You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays https://nixos.wiki/wiki/Overlays That page says: "Overlays provide a method to extend and change nixpkgs" I don't want to change something. I want to simply pin a version. This is neither simple, nor scalable, nor maintainable (also here: https://news.ycombinator.com/item?id=28591202 https://news.ycombinator.com/item?id=28591202): Overriding a version self: super: { sl = super.sl.overrideAttrs (old: { src = super.fetchFromGitHub { owner = "mtoyoda"; repo = "sl"; rev = "923e7d7ebc5c1f009755bdeb789ac25658ccce03"; # If you don't know the hash, the first time, set: # sha256 = "0000000000000000000000000000000000000000000000000000"; # then nix will fail the build with such an error message: # hash mismatch in fixed-output derivation '/nix/store/m1ga09c0z1a6n7rj8ky3s31dpgalsn0n-source': # wanted: sha256:0000000000000000000000000000000000000000000000000000 # got: sha256:173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4 sha256 = "173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4"; }; }); }
    - rvanlaar 5y ago
      Reading your linked post, it seems you are wrestling with how Nix works. Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do. As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?
      - dmitriid 5y ago
        > Reading your linked post, it seems you are wrestling with how Nix works. Not only me. > That's because it's solving slightly different problems than package managers currently do. We keep hearing this claim, and hardly any proof of that. > As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable? 1. Commit hashes are not versions 2. Hunting down every commit hash of every package to pin down the exact version is neither maintainable nor scalable

Arkh4m 5y ago

First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to reload your shell. Most current version managers either do it themselves through shell hooks or ask you to install direnv. Point taken on using brew: I've changed it to use nix-env. Third. Yep. Sort of like having to learn English before you can learn programming. Fourth. As they say: start with the basics. Fifth. No other package manager can freeze the complete dependency set you are using AND allow you to revert it exactly when things don't work. That's the power of declarative, reproducible builds: you try to update and it doesn't work? No problem, revert to the last working version and things are all good again. Sixth. Ever tried updating a project using a Dockerfile that uses an old version of ubuntu? Then you can't find the packages anymore or no is building them anymore for the new version of Ubuntu and you have to pull random PPAs from the Internet to get things to work? In Nix, you can keep two pinned nixpkgs versions at the same time. In this way you can keep working on upgrading your project one working step at the time. So yeah, it's not just cHeCKmATe FP-atheists sort of stuff.

throwaway984393 5y ago
For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them after they're built the first time in an artifact repository. Any builds of your app that use a container need to be versioned to prove they've been tested successfully, anyway, and you want to keep them around to do fast rollbacks without having to kick off a build just to roll back. So you don't need reproducibility for reliability. It's mostly used for security: build on two siloed systems, compare the results. Version-pinning in general is to prevent silent upgrades that break your builds. But you also don't want to version-pin everything, as you want security patches to get automatically applied with regularly-recurring builds. So in practice, you stick with a major branch of something, silently accept upgraded packages or minor version bumps, and have an automated system flag if you aren't running the latest security packages. All of that works fine with Docker and Apt. More often than breakage due to silent upgrade is the security patch problem, where somebody pinned to a version 4 years ago and has never patched, and it's been so long that all the downstream effects of patching force you to do an entire lift-and-shift to new everything. Gradual continuous updates (stick to a major version, run tests) is the best middle ground. Modern projects with Docker containers have standardized their tagging around this.

GoblinSlayer 5y ago

Imagine having a whole language, but still running shell scripts to create folders and replace text. I mean even rpm can create folders declaratively.

takeda 5y ago

> First, you want a "dependency manager". That's not what Nix is, clearly. Nix is a package manager. This is not true. The defining point about Nix is that it allows to define all dependencies explicitly. Every derivation in it is built inside of a sandbox with no access to network and restricted filesystem. This ensures that nothing is accidentally missed. Package management is just one of features. > Second, to use this package manager, you first need to install direnv. How do you install it? with brew, a different package manager. direnv is not needed to use Nix, it's just a nice add-on. It's like you don't need Ranger to navigate in a file system, but it is nice. Besides, you can install direnv through nix, I use it this way. Even nix is installed by itself as well. > Third, you have to learn a new functional programming language. Right. Because normally to put together a toolbox, I often learn to speak a few phrases in Swahili first. Well, yes you do, but language is actually quite simple it's the nixpkgs (repo containing all packages) that's quite complex. Nix's purely functional, lazily evaluated properties exactly fit as a language describing dependencies. > Fourth, finally, we get to install a simple Unix program, that any package manager could have provided. If you were trying to install a package, you don't need to learn anything, you just install it (for example to install ranger you just run nix-env -iA nixpkgs.ranger). Nix language is only needed if you want to create a new package. > For the fifth trick, freezing dependencies, you first have to have all the correct versions of all the dependencies to do what you want. How do you establish the right ones? Manually. Just like with any other package manager that builds apps against a specific tree of build deps. "Reproducibility!" Because no other package manager could possibly download the same tarballs and run the same commands. Must be all that functional programming magic. > And sixth, the idea that this will work forever. Right. Because any other distro and package manager could not possibly work again in the future, with a mirror of all the packages in a release. That's only for super cool futuristic package managers. No way to reproduce the same packages in the future with old package managers. > Look, Nixians, this is all old hat. Every decent package manager can do all these things, just in a less complicated way. Modern systems use containers, and they don't need Nix for that. Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. Nix delivers what docker promised and ultimately failed to deliver. Docker promised to reproduce developer's environment to production. What it did was to zip developer's computer and deploy it. When docker got adopted, relying on images was impractical, so for deployment Dockerfile was used, but that file is not much different than a shell script. Nix instead describes the entire dependency tree down to libc. Because the starting state and all dependencies are known it can always create the same result, that's the biggest selling point of Nix to me.

globular-toast 5y ago

> Nix is basically just the new Gentoo: a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. As a Gentoo user and someone who has tried and grokked Nix/Guix, this is not true at all. Gentoo is essentially a system for creating distributions, a meta-distro if you like. It just so happens to be something that appeals to someone like me to run at home because, well, why not? I know exactly what I need/want on my computer and this lets me build my own custom distro tailored for me. Nix/Guix is something completely different. It addresses real problems that arise in a variety of places in an elegant way. Containers are another solution to some of these problems, but come with their own tradeoffs. Your blanket statement about "professionals" makes no sense. I don't use Gentoo at work because it's not my job to maintain custom Linux systems or create distros. But guess what? Not everyone has the same job. You don't speak for all "professionals". I can distinctly remember around 2007 people saying this exact thing about git. I was told geeks were only learning it to make themselves feel clever and that SVN was fine. Well look how that turned out. I'm glad I ignored those people.

shantnutiwari 5y ago

I've heard about nix here often, but everytime they show toy examples. And if you want to do anything complicated, it's all get this hash, use this trick, this extra tool etc etc. At which point, it's just easier to stick with what you have. >> a distro for hobbyists who tell themselves they're advanced while all the professionals use something else. yeah, getting the same vibe. Lots of hype not backed by any evidence. For me, to start off, I'd like to see a real example, not some made up simple use case