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://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.
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://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.