4 ms·

> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for

> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution" for that is to dig through some commit hashes, and use those. Commit hashes are not versions. 2. Your example points to a completely random version of a package The previous issue already points to a random version, apparently, but this is further compounded by the fact that "ruby_2_6" and "nodejs-10_x" point to a random version that is available at the time. To truly make the claim that nix allows reproducible builds, it needs to provide: - a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is - a way to actually properly pin package versions. Something that all package/dependency managers allow you to. If I want to pin ruby to exactly 2.6.7, for an actual reproducible build, what is nix' solution for that?

ducktective 5y ago
You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
- dmitriid 5y ago
  > You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes 1. How? You'd think such a simple thing, especially in the context of "ditch version managers" would be easy and warrant at least an example. So far I've had: - ignoring the question or avoiding the answer - one answer "just use overlays" with no example - one answer "just use flakes" with no example 2. It's a separate, unstable feature It amazes me that after 18 years, you still need (probably? no idea) to use some entirely separate feature that is still unstable/experimental and uses an entirely different system of describing what's needed than nix proper. And still no answer how to do the thing that is literally required for every single reproducible build: pin a tool to a specific version. Meanwhile tools that we're supposed to ditch are as simple as rvm install 2.1.1 rvm use 2.1.1
  - ducktective 5y ago
    Looks like you are right. Relevant issue: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327
    - dmitriid 5y ago
      It amazes me how many people in that thread keep saying that we shouldn't even want it, that this is not what nix is about, that no one should install historical versions etc. BTW, another issues linked is from 2015 https://github.com/NixOS/nixpkgs/issues/9682 https://github.com/NixOS/nixpkgs/issues/9682 Given that my question never got an answer in HN (not until I had a discussion with the original article's author on Twitter and he posted this solution), it's clear that: - this issue still exists - how to do this is still not properly documented - no one really knows how to do it in nix - this extremely common functionality that is literally required for actual reproducible builds is entirely glossed over in all the articles praising nix
      - ducktective 5y ago
        Link to the thread for other people: https://nitter.net/dmitriid/status/1439957729909559298#m https://nitter.net/dmitriid/status/1439957729909559298#m Ju (@Arkham) proposed a solution: 1- Finding the commit hash of of nixpkgs which contains a specific version of a dependency (e.g. ruby 2.6.3) and use that to bring in the dependency 2- If a specific version does not exist in any of the hashes, we should patch the `.nix` file and build the dependency ourselves. This causes all other transitive dependencies to be rebuilt. Arguments against 1: Why should we rely on an external thrid-party webservice to find the hashes of a specific package? This should be integrated to the `nix` tooling. Hope the community incorporates history search into the tooling :) Arguments against 2: @dimitriid says the solution is cumbersome. Arguments for 2: - What if rvm or nvm don't have a specific version or deprecate that version from their repos? At least there is a solution via Nix. - What are you going to do for other languages which don't have a package/VM manager like Java, C/C++, etc? At least the Nix solution is universal and you don't have to learn the tooling of every technology. I think @technomancy over at Lobste.rs has a wise take on this issue: https://lobste.rs/s/emyfhx/ditch_your_version_manager#c_5acgpf https://lobste.rs/s/emyfhx/ditch_your_version_manager#c_5acg... > I feel like Nix/Guix vs Docker is like … do you want the right idea with not-enough-polish-applied, or do you want the wrong idea with way-too-much-polish-applied?
jbboehr 5y ago
> To truly make the claim that nix allows reproducible builds, it needs to provide: - a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is I don't see why a commit hash in insufficient to declare a package reproducible. For my system, I just use channels, but for anything mission critical, I think most people pin their commit hash of nixpkgs [0]. A pinned commit of nixpkgs will produce the exact same set of packages, forever. > a way to actually properly pin package versions The way you do this is to pull in a specific commit of nixpkgs (you can install packages from many versions of it at the same time, if you want). Alternatively, you can manually vendor the package file, which is what I usually do for one or two packages. [0]: https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs
- dmitriid 5y ago
  > I don't see why a commit hash in insufficient to declare a package reproducible. I didn't say it wasn't sufficient. The problem is that you need to find this hash, and there's no way to do it. See this issue and discussion there: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327
Arkh4m 5y ago
Here is an example if you absolutely want to pin Ruby to 2.6.7 while pulling all other packages from a more recent set of packages https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5739 https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5... I found the nixpkgs version using this tool: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=ruby https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable... Note that Ruby 2.6.8 fixes three severe vulnerabilities present in Ruby 2.6.7, while being backward compatible, so I don't see why you'd want that.

ducktective 5y ago

You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes

dmitriid 5y ago
> You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes 1. How? You'd think such a simple thing, especially in the context of "ditch version managers" would be easy and warrant at least an example. So far I've had: - ignoring the question or avoiding the answer - one answer "just use overlays" with no example - one answer "just use flakes" with no example 2. It's a separate, unstable feature It amazes me that after 18 years, you still need (probably? no idea) to use some entirely separate feature that is still unstable/experimental and uses an entirely different system of describing what's needed than nix proper. And still no answer how to do the thing that is literally required for every single reproducible build: pin a tool to a specific version. Meanwhile tools that we're supposed to ditch are as simple as rvm install 2.1.1 rvm use 2.1.1
- ducktective 5y ago
  Looks like you are right. Relevant issue: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327
  - dmitriid 5y ago
    It amazes me how many people in that thread keep saying that we shouldn't even want it, that this is not what nix is about, that no one should install historical versions etc. BTW, another issues linked is from 2015 https://github.com/NixOS/nixpkgs/issues/9682 https://github.com/NixOS/nixpkgs/issues/9682 Given that my question never got an answer in HN (not until I had a discussion with the original article's author on Twitter and he posted this solution), it's clear that: - this issue still exists - how to do this is still not properly documented - no one really knows how to do it in nix - this extremely common functionality that is literally required for actual reproducible builds is entirely glossed over in all the articles praising nix
    - ducktective 5y ago
      Link to the thread for other people: https://nitter.net/dmitriid/status/1439957729909559298#m https://nitter.net/dmitriid/status/1439957729909559298#m Ju (@Arkham) proposed a solution: 1- Finding the commit hash of of nixpkgs which contains a specific version of a dependency (e.g. ruby 2.6.3) and use that to bring in the dependency 2- If a specific version does not exist in any of the hashes, we should patch the `.nix` file and build the dependency ourselves. This causes all other transitive dependencies to be rebuilt. Arguments against 1: Why should we rely on an external thrid-party webservice to find the hashes of a specific package? This should be integrated to the `nix` tooling. Hope the community incorporates history search into the tooling :) Arguments against 2: @dimitriid says the solution is cumbersome. Arguments for 2: - What if rvm or nvm don't have a specific version or deprecate that version from their repos? At least there is a solution via Nix. - What are you going to do for other languages which don't have a package/VM manager like Java, C/C++, etc? At least the Nix solution is universal and you don't have to learn the tooling of every technology. I think @technomancy over at Lobste.rs has a wise take on this issue: https://lobste.rs/s/emyfhx/ditch_your_version_manager#c_5acgpf https://lobste.rs/s/emyfhx/ditch_your_version_manager#c_5acg... > I feel like Nix/Guix vs Docker is like … do you want the right idea with not-enough-polish-applied, or do you want the wrong idea with way-too-much-polish-applied?

jbboehr 5y ago

> To truly make the claim that nix allows reproducible builds, it needs to provide: - a way to specify versions that don't depend on the commit hash of a "nixpck channel" whatever that is I don't see why a commit hash in insufficient to declare a package reproducible. For my system, I just use channels, but for anything mission critical, I think most people pin their commit hash of nixpkgs [0]. A pinned commit of nixpkgs will produce the exact same set of packages, forever. > a way to actually properly pin package versions The way you do this is to pull in a specific commit of nixpkgs (you can install packages from many versions of it at the same time, if you want). Alternatively, you can manually vendor the package file, which is what I usually do for one or two packages. [0]: https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

dmitriid 5y ago
> I don't see why a commit hash in insufficient to declare a package reproducible. I didn't say it wasn't sufficient. The problem is that you need to find this hash, and there's no way to do it. See this issue and discussion there: https://github.com/NixOS/nixpkgs/issues/93327 https://github.com/NixOS/nixpkgs/issues/93327

Arkh4m 5y ago

Here is an example if you absolutely want to pin Ruby to 2.6.7 while pulling all other packages from a more recent set of packages https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5739 https://gist.github.com/Arkham/31297c1d75fc59f723a50063bc0f5... I found the nixpkgs version using this tool: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=ruby https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable... Note that Ruby 2.6.8 fixes three severe vulnerabilities present in Ruby 2.6.7, while being backward compatible, so I don't see why you'd want that.