> Why wouldn't it be available? Nix packages are on github. [1]
1. Git history can be re-written.
2. Nix packages still point to some specific versions that may or not may be available [1]
So how exactly is nix so much different from "a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore"?
> That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post a whole later you'll probably get a newer version.
That is only true insofar as you use a "get me the latest version of the package, regardless".
In any sane system the solution to that is to do `npm install <specific version>` or `gem install <specific version>` or `pip install <specific version>` or `brew install <specific version>`
In nix, apparently it is:
- find the commit hash of the nix package channel
- pull a package that still points to a rather random version
Which raises another question:
nixpackages 21.05's ruby_2_6 is actually ruby 2.6.8. It's not available in nixpackages 20.09. But 21.05 doesn't contain the newer Go versions.
So, if I wanted ruby 2.6.7 and go 1.13 (neither are available in either 21.05 or 20.09), I would do what exactly? Or if I wanted ruby_2_6 (available in 21.05) and go_1_16 (available in 20.09)? All other package/dependency management tools don't even have such a problem.
So far I've asked this at least three different times, and every time the question been ignored or avoided. But sure, nix is amazing, and is a reproducible build system unlike any other.
It's been around for at least 18 years. You'd think there would be easy answers to these questions by now.
[1] Example, https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
1. Git history can be re-written.
2. Nix packages still point to some specific versions that may or not may be available [1]
So how exactly is nix so much different from "a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore"?
> That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post a whole later you'll probably get a newer version.
That is only true insofar as you use a "get me the latest version of the package, regardless".
In any sane system the solution to that is to do `npm install <specific version>` or `gem install <specific version>` or `pip install <specific version>` or `brew install <specific version>`
In nix, apparently it is:
- find the commit hash of the nix package channel
- pull a package that still points to a rather random version
Which raises another question:
nixpackages 21.05's ruby_2_6 is actually ruby 2.6.8. It's not available in nixpackages 20.09. But 21.05 doesn't contain the newer Go versions.
So, if I wanted ruby 2.6.7 and go 1.13 (neither are available in either 21.05 or 20.09), I would do what exactly? Or if I wanted ruby_2_6 (available in 21.05) and go_1_16 (available in 20.09)? All other package/dependency management tools don't even have such a problem.
So far I've asked this at least three different times, and every time the question been ignored or avoided. But sure, nix is amazing, and is a reproducible build system unlike any other.
It's been around for at least 18 years. You'd think there would be easy answers to these questions by now.
[1] Example, https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...