5 ms·

NixOS claims to be "reproducible", "declarative" and "reliable". Yet there is no way of "declaring" which version of given package you want to install, which mi

by harvie 5y ago

NixOS claims to be "reproducible", "declarative" and "reliable". Yet there is no way of "declaring" which version of given package you want to install, which might be seen as hard requirement for some build to be "reproducible". You might need to stick to some old (but tested) version when building "reliable" system.

seniorivn 5y ago
it's not as harsh as you describe it, but it's a well know issue in nix community which is why flakes were introduced
jskrablin 5y ago
You can use nix-shell to create complete runtime environments with pinned software versions. Not sure re nix flakes (it's been a while since I last used Nix) however I found nix-shell pretty good for exactly this type of stuff.
q3k 5y ago
> Yet there is no way of "declaring" which version of given package you want to install But there is? First, by pinning nixpkgs you pin to whatever set of versions was within nixpkgs at the time. Then, if you want to change the version of a package, you can use overlays to poke at what source version is being used to build a package (or what flags it's being built with, etc). There's also nothing preventing your from mixing derivations from multiple nixpkgs pins within a single nixpkgs/nixos fixpoint for your system. Stuff that in your shell.nix or /etc/nixos/configuration.nix or just nix-build it straight from a small .nix file.
- YuukiRey 5y ago
  Overlays are very hit and miss for this. It's important for non-nix people to understand that with an overlay you typically only change the version of the source of the program. Essentially think of it like downloading an older git commit. But quite often the Nix build instructions won't work with arbitrary commits. A file that's being patched in the current Nixpkgs checkout might not exist in the version of the source you check out. Then you start playing whack a mole where you override more and more of the derivation. Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. So the mechanisms you describe are in my experience very good in theory but often lacking in practice.
  - asymmetric 5y ago
    > Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. Then you could get the package from a fork of nixpkgs where it is present.
  - microtonal 5y ago
    Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. Yeah, but also keep in mind that uses the older version, plus older versions of all its transitive dependencies (from the same nixpkgs checkout). So, you could end up with multiple versions of glibc and other commonly-used libraries, but worse -- many known security vulnerabilities as well. Another practical annoyance is that overriding attributes often does not work across a derivation. E.g. overriding the version attribute does not override the same version in the src attribute (which is used to download the sources) [1]. So, you may have to override the attribute in several places. [1] Unless the derivation is defined in a non-canonical way: https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkgs/8293 https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkg...
- asymmetric 5y ago
  Here is an example: https://nixos.wiki/wiki/Overlays#Overriding_a_version https://nixos.wiki/wiki/Overlays#Overriding_a_version
zwiek 5y ago
Indeed, when you depend on a package from a Nix channel, you implicitly depend always on the latest definition of that package in that channel. When the version matters, Nix has separate packages for separate versions. There are separate Nix packages for Python 2.7, 3.7, 3.8, 3.9 or 3.10, and there's OpenJDK 8, 11 and 17, etc. You probably don't want to depend on an overly specific version anyway. If a security fix for one of your dependencies is released, you want it. Furthermore, CI ensures that everything within a channel is maximally consistent.
ducktective 5y ago
Follow this thread. We had a through discussion about this. https://news.ycombinator.com/item?id=28591661 https://news.ycombinator.com/item?id=28591661

by harvie 5y ago

seniorivn 5y ago

it's not as harsh as you describe it, but it's a well know issue in nix community which is why flakes were introduced

jskrablin 5y ago

You can use nix-shell to create complete runtime environments with pinned software versions. Not sure re nix flakes (it's been a while since I last used Nix) however I found nix-shell pretty good for exactly this type of stuff.

q3k 5y ago

> Yet there is no way of "declaring" which version of given package you want to install But there is? First, by pinning nixpkgs you pin to whatever set of versions was within nixpkgs at the time. Then, if you want to change the version of a package, you can use overlays to poke at what source version is being used to build a package (or what flags it's being built with, etc). There's also nothing preventing your from mixing derivations from multiple nixpkgs pins within a single nixpkgs/nixos fixpoint for your system. Stuff that in your shell.nix or /etc/nixos/configuration.nix or just nix-build it straight from a small .nix file.

YuukiRey 5y ago
Overlays are very hit and miss for this. It's important for non-nix people to understand that with an overlay you typically only change the version of the source of the program. Essentially think of it like downloading an older git commit. But quite often the Nix build instructions won't work with arbitrary commits. A file that's being patched in the current Nixpkgs checkout might not exist in the version of the source you check out. Then you start playing whack a mole where you override more and more of the derivation. Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. So the mechanisms you describe are in my experience very good in theory but often lacking in practice.
- asymmetric 5y ago
  > Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. Then you could get the package from a fork of nixpkgs where it is present.
- microtonal 5y ago
  Using an older Nixpkgs checkout might have a higher rate of success but if Nixpkgs never included the version you need in the first place that also doesn't work. Yeah, but also keep in mind that uses the older version, plus older versions of all its transitive dependencies (from the same nixpkgs checkout). So, you could end up with multiple versions of glibc and other commonly-used libraries, but worse -- many known security vulnerabilities as well. Another practical annoyance is that overriding attributes often does not work across a derivation. E.g. overriding the version attribute does not override the same version in the src attribute (which is used to download the sources) [1]. So, you may have to override the attribute in several places. [1] Unless the derivation is defined in a non-canonical way: https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkgs/8293 https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkg...
asymmetric 5y ago
Here is an example: https://nixos.wiki/wiki/Overlays#Overriding_a_version https://nixos.wiki/wiki/Overlays#Overriding_a_version

zwiek 5y ago

Indeed, when you depend on a package from a Nix channel, you implicitly depend always on the latest definition of that package in that channel. When the version matters, Nix has separate packages for separate versions. There are separate Nix packages for Python 2.7, 3.7, 3.8, 3.9 or 3.10, and there's OpenJDK 8, 11 and 17, etc. You probably don't want to depend on an overly specific version anyway. If a security fix for one of your dependencies is released, you want it. Furthermore, CI ensures that everything within a channel is maximally consistent.

ducktective 5y ago

Follow this thread. We had a through discussion about this. https://news.ycombinator.com/item?id=28591661 https://news.ycombinator.com/item?id=28591661