6 ms·

>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 sp

>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.
- ducktective 5y ago
  Sorry if I may have come up as a Nix professional/proponent. I'm actually a nix beginner and as can be seen in this thread, I've asked the author similar question to yours. Using Ubuntu, I have been bitten by glibc and other dependency mismatch in my projects and I'm looking for something more elegant than docker/VBox. I've read posts from both sides of this discussion. > Oh. Wait. There's literally no such way. I think there is? Check to see if the nixpkgs history have that version (+), if not, patch the derivation (could be as simple as bumping the version and recalculating the hash, or, doing so could cause a breakage in one of the transitive dependencies, at which point, you have to fix that also (meaning a version increment of decrement for the dependency or more. Essentially you have to build the specific ruby version down to all its dependencies) (+) How can we see what versions are available in nixpkgs history? It seems we have to use third-party webservices! I agree with you here that this should have been implemented in the nix tooling itself. I know of two such services: https://4shells.com/nixdb/pkg/ruby/2.6.6 https://4shells.com/nixdb/pkg/ruby/2.6.6 https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=ruby https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable... I think this also answers that quote from the github issue. > What was this solution again? From what I understood, in the project `.nix` file, we inherent from a forked nixpkgs repo which has our patched `default.nix` in the ruby folder, for building ruby. (Nix pros, correct me if I'm wrong here). Now we have to build all deps locally since a matching hash would not be present on Nix cache servers. Now, with nvm, how could you guarantee that a particular version would not conflict with one the host OSs low-level libraries (Like glibC)? The difficulty and complexity of patching the Nix derivation has to do with this part. In Ubuntu/Debian, you can't simply mess with system level low level libraries.
  - dmitriid 5y ago
    >> Oh. Wait. There's literally no such way. > I think there is? There is no official way to do that. There's no history. There are no tools in nix to do that. As you noted, you have to rely on the kindness of strangers to provide this service. Here's lazamar's own explanation why he built the tool: https://lazamar.github.io/download-specific-package-version-with-nix/ https://lazamar.github.io/download-specific-package-version-... Look at the beginning of the "automating" section to see what is required to do all that with nix. On top of that, in the entire discussion here exactly one person could actually show how to pin something to a version, so it's poorly documented, extremely complex and not really understood even for people who propose nix. > Now, with nvm, how could you guarantee that a particular version would not conflict with one the host OSs low-level libraries You probably don't, or stick it in a container somewhere. But this is about tradeoffs: does nix provide enough tradeoffs to use this complicated, complex and poorly documented system?

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.

ducktective 5y ago
Sorry if I may have come up as a Nix professional/proponent. I'm actually a nix beginner and as can be seen in this thread, I've asked the author similar question to yours. Using Ubuntu, I have been bitten by glibc and other dependency mismatch in my projects and I'm looking for something more elegant than docker/VBox. I've read posts from both sides of this discussion. > Oh. Wait. There's literally no such way. I think there is? Check to see if the nixpkgs history have that version (+), if not, patch the derivation (could be as simple as bumping the version and recalculating the hash, or, doing so could cause a breakage in one of the transitive dependencies, at which point, you have to fix that also (meaning a version increment of decrement for the dependency or more. Essentially you have to build the specific ruby version down to all its dependencies) (+) How can we see what versions are available in nixpkgs history? It seems we have to use third-party webservices! I agree with you here that this should have been implemented in the nix tooling itself. I know of two such services: https://4shells.com/nixdb/pkg/ruby/2.6.6 https://4shells.com/nixdb/pkg/ruby/2.6.6 https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=ruby https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable... I think this also answers that quote from the github issue. > What was this solution again? From what I understood, in the project `.nix` file, we inherent from a forked nixpkgs repo which has our patched `default.nix` in the ruby folder, for building ruby. (Nix pros, correct me if I'm wrong here). Now we have to build all deps locally since a matching hash would not be present on Nix cache servers. Now, with nvm, how could you guarantee that a particular version would not conflict with one the host OSs low-level libraries (Like glibC)? The difficulty and complexity of patching the Nix derivation has to do with this part. In Ubuntu/Debian, you can't simply mess with system level low level libraries.
- dmitriid 5y ago
  >> Oh. Wait. There's literally no such way. > I think there is? There is no official way to do that. There's no history. There are no tools in nix to do that. As you noted, you have to rely on the kindness of strangers to provide this service. Here's lazamar's own explanation why he built the tool: https://lazamar.github.io/download-specific-package-version-with-nix/ https://lazamar.github.io/download-specific-package-version-... Look at the beginning of the "automating" section to see what is required to do all that with nix. On top of that, in the entire discussion here exactly one person could actually show how to pin something to a version, so it's poorly documented, extremely complex and not really understood even for people who propose nix. > Now, with nvm, how could you guarantee that a particular version would not conflict with one the host OSs low-level libraries You probably don't, or stick it in a container somewhere. But this is about tradeoffs: does nix provide enough tradeoffs to use this complicated, complex and poorly documented system?