3 ms·

This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed. What you describe as a deal-kil

This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed. What you describe as a deal-killer is just purity and safety. Updating a build input gives no guarantee that the build output will be the same or even work. Sure, as smart humans we can say “I know this change does not impact X, so it’s fine”, but NixOS is based partly on the claim that we do not do that reliably or consistently, and tries to save us from ourselves. Yes, it means more rebuilding, but it also means less debugging, confusion, etc., when things do go awry.

AshamedCaptain 5y ago
> What you describe as a deal-killer is just purity and safety. It's not really "pure" since you are packaging software with side-effects to begin with. Even if you use the same text bit by bit it's also no guarantee that the output will be the same or that even it will work. You are still relying on some human claiming that it will do. So the advantage is not really that big in practice, and the disadvantage means rebuilding the world on every low-level package change. Even Gentoo fares better in that regard. And yes, I am aware that the deal-killer is at the core of these approaches, which is why I don't take them seriously.
- zaphar 5y ago
  I think you might be vastly understating the advantage here. I've been the guy who shipped software that "worked on my machine" but didn't work in production because on my machine there was a system installed dependency that got used but didn't exist in production and the only way to discover that was to ship to production. Nix makes that a far less likely scenario. It get's a lot of things wrong in how it achieves that but it fixes a real and very substantive problem.
- amarshall 5y ago
  Sure, if you have a program that outputs a random number, NixOS doesn’t make it suddenly always output the same number (would one even want that?). Nix aims to remove side-effects from the build system (and some aspects of the execution environment), not from within the program itself. Whether the program itself is pure is up to it, not NixOS. But the point is that NixOS eliminates whole classes of why the output may be different.

AshamedCaptain 5y ago

> What you describe as a deal-killer is just purity and safety. It's not really "pure" since you are packaging software with side-effects to begin with. Even if you use the same text bit by bit it's also no guarantee that the output will be the same or that even it will work. You are still relying on some human claiming that it will do. So the advantage is not really that big in practice, and the disadvantage means rebuilding the world on every low-level package change. Even Gentoo fares better in that regard. And yes, I am aware that the deal-killer is at the core of these approaches, which is why I don't take them seriously.

zaphar 5y ago
I think you might be vastly understating the advantage here. I've been the guy who shipped software that "worked on my machine" but didn't work in production because on my machine there was a system installed dependency that got used but didn't exist in production and the only way to discover that was to ship to production. Nix makes that a far less likely scenario. It get's a lot of things wrong in how it achieves that but it fixes a real and very substantive problem.
amarshall 5y ago
Sure, if you have a program that outputs a random number, NixOS doesn’t make it suddenly always output the same number (would one even want that?). Nix aims to remove side-effects from the build system (and some aspects of the execution environment), not from within the program itself. Whether the program itself is pure is up to it, not NixOS. But the point is that NixOS eliminates whole classes of why the output may be different.