5 ms·

Link to the thread for other people: https://nitter.net/dmitriid/status/1439957729909559298#m https://nitter.net/dmitriid/status/1439957729909559298#m Ju (@Ar

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?

dmitriid 5y ago
> Arguments for 2: > - What if rvm or nvm don't have a specific version Let's get back to reality for a second. For most development needs this is a hypothetical situation. Right now, in reality, ruby-lang hosts versions dating to 2002. Also, right now, in reality nix limits the number of available versions. Quote: "in NixPkgs we choose to restrict the number of maintained versions", https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-661986395 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-6... So it's already worse than the hypothetical "what if rvm don't have a specific version". Also, right now, in reality there's no easy way to pin a version of a tool in nix. Except going to a third-party website (lazamar's site), hope that your specific version is listed there (he only maintains a snapshot of a few years), and dig through nixpckg commit hashes. And this has been a known issue for as long as nix has been around. 18 years, at least. And we're still hoping that someone somewhere will incorporate this into standard tooling. You yourself linked to an issue on this. I'd like to link to a reply in that issue: https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-661960469 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-6... And to this reply: https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-778546569 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-7... > What are you going to do for other languages which don't have a package/VM manager like Java, C/C++, etc? That varies between languages, of course. I have several Java versions installed side-by-side. C/C++ is worse because they are mostly stuck in 1960s, tooling-wise (though on windows you can have multiple msvcrt versions installed side-by-side). This still can be (and is) handled. And nix doesn't offer great advantages, except providing a complex, complicated, poorly documented tool.
- ducktective 5y ago
  >Right now, in reality, ruby-lang hosts versions dating to 2002. OK, so you want to pin ruby 1.3.4 in your project and use a ruby gem that is dependent on a specific glibc (or maybe some standard ruby library itself is dependent on a low-level C dependency.). With python these stuff happens all the time. What would you do? Craft a dockerfile inheriting from an old Debian and hope ruby 1.3.4 installed with rvm would play nicely with this specific version of Debian? How do you find what version of say, Ubuntu, has fixed security updates of the low-level dependencies of your project? And what happens if the apt-managed JRE v.1.6.x in that instance would break other parts of the project that was dependent on JRE v1.6.y? >That varies between languages, of course. Well, that's the point. For each technology, you have to handle their specific "VM manager" and put up with their quirks + random state-changes imposed by apt. With Nix, the solution would not vary between languages, setups and teams. I mean, at least theoretically, the Nix/Guix way makes much more sense than shipping the whole state of the computer (with docker).
  - dmitriid 5y ago
    > OK, so you want to pin ruby 1.3.4 in your project and use a ruby gem that is dependent on a specific glibc (or maybe some standard ruby library itself is dependent on a low-level C dependency.). With python these stuff happens all the time. What would you do? What amazes me is how you keep asking what would happen in other places instead of asking/answering "how easy/convenient would that be in nix". Let me give you a different question: I have ruby x.x.x. A serious security issue is discovered, and everyone is encouraged to upgrade to ruby x.x.x+1. Let's see how easy it is to do in nix which is "a tool that takes a unique approach to package management and system configuration." Oh. Wait. There's literally no such way. Except manually looking for git commit hashes... somewhere. Let me quote a reply from the issue you yourself linked: --- start quote --- I've read the Nix Package Manager Guide, but everything in there about reproducibility seems to point to installing (and therefore finding) specific versions. I mean the first title in chapter 1 is multiple versions Any other multiple-simultaneous-version managers: asdf, kiex, gvm, rvm, rbenv, pyenv, jenv, nvm, Renv, luavm, all have a list-available-versions as either their 1st or top-5 most-used commands. But nix has 5.3K stars, so there must be something I'm not understanding if nix is missing something so vital --- end quote --- > With Nix, the solution would not vary What was this solution again? In the entirety of the discussion to this post there was exactly one person (the author of the article) who could show how to do it. Even nix proponents don't know how to do that, apparently.

dmitriid 5y ago

> Arguments for 2: > - What if rvm or nvm don't have a specific version Let's get back to reality for a second. For most development needs this is a hypothetical situation. Right now, in reality, ruby-lang hosts versions dating to 2002. Also, right now, in reality nix limits the number of available versions. Quote: "in NixPkgs we choose to restrict the number of maintained versions", https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-661986395 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-6... So it's already worse than the hypothetical "what if rvm don't have a specific version". Also, right now, in reality there's no easy way to pin a version of a tool in nix. Except going to a third-party website (lazamar's site), hope that your specific version is listed there (he only maintains a snapshot of a few years), and dig through nixpckg commit hashes. And this has been a known issue for as long as nix has been around. 18 years, at least. And we're still hoping that someone somewhere will incorporate this into standard tooling. You yourself linked to an issue on this. I'd like to link to a reply in that issue: https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-661960469 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-6... And to this reply: https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-778546569 https://github.com/NixOS/nixpkgs/issues/93327#issuecomment-7... > What are you going to do for other languages which don't have a package/VM manager like Java, C/C++, etc? That varies between languages, of course. I have several Java versions installed side-by-side. C/C++ is worse because they are mostly stuck in 1960s, tooling-wise (though on windows you can have multiple msvcrt versions installed side-by-side). This still can be (and is) handled. And nix doesn't offer great advantages, except providing a complex, complicated, poorly documented tool.

ducktective 5y ago
>Right now, in reality, ruby-lang hosts versions dating to 2002. OK, so you want to pin ruby 1.3.4 in your project and use a ruby gem that is dependent on a specific glibc (or maybe some standard ruby library itself is dependent on a low-level C dependency.). With python these stuff happens all the time. What would you do? Craft a dockerfile inheriting from an old Debian and hope ruby 1.3.4 installed with rvm would play nicely with this specific version of Debian? How do you find what version of say, Ubuntu, has fixed security updates of the low-level dependencies of your project? And what happens if the apt-managed JRE v.1.6.x in that instance would break other parts of the project that was dependent on JRE v1.6.y? >That varies between languages, of course. Well, that's the point. For each technology, you have to handle their specific "VM manager" and put up with their quirks + random state-changes imposed by apt. With Nix, the solution would not vary between languages, setups and teams. I mean, at least theoretically, the Nix/Guix way makes much more sense than shipping the whole state of the computer (with docker).
- dmitriid 5y ago
  > OK, so you want to pin ruby 1.3.4 in your project and use a ruby gem that is dependent on a specific glibc (or maybe some standard ruby library itself is dependent on a low-level C dependency.). With python these stuff happens all the time. What would you do? What amazes me is how you keep asking what would happen in other places instead of asking/answering "how easy/convenient would that be in nix". Let me give you a different question: I have ruby x.x.x. A serious security issue is discovered, and everyone is encouraged to upgrade to ruby x.x.x+1. Let's see how easy it is to do in nix which is "a tool that takes a unique approach to package management and system configuration." Oh. Wait. There's literally no such way. Except manually looking for git commit hashes... somewhere. Let me quote a reply from the issue you yourself linked: --- start quote --- I've read the Nix Package Manager Guide, but everything in there about reproducibility seems to point to installing (and therefore finding) specific versions. I mean the first title in chapter 1 is multiple versions Any other multiple-simultaneous-version managers: asdf, kiex, gvm, rvm, rbenv, pyenv, jenv, nvm, Renv, luavm, all have a list-available-versions as either their 1st or top-5 most-used commands. But nix has 5.3K stars, so there must be something I'm not understanding if nix is missing something so vital --- end quote --- > With Nix, the solution would not vary What was this solution again? In the entirety of the discussion to this post there was exactly one person (the author of the article) who could show how to do it. Even nix proponents don't know how to do that, apparently.