How do I pin ruby version to 2.6.3 in Nix? This is given to me for free in other tools. As are reproducible builds because all modern package/dependency managers lock versions.
See that `rev` line in the sources.json? The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what. That alone resolves a huge category of potential problems.
There's much, much more to it. Nix stores each package in its own path. [2] This makes it possible to install multiple versions of one application or library next to each other. With the power of direnv only the versions one needs are included.
[1] https://github.com/tikitu/jsmin/issues/33
[2] > ls /nix/store/ |head 000dm655691b5zis34klvhlil3hrv7j5-fftw-3.3.9.tar.gz.drv 005m4pqd29k976if66fpbggjsdxhchdg-python3.8-astroid-2.5.1.drv 007hqps3i495yjk223vhckin27vggk81-recode-3.7.8.tar.gz.drv 009815w1n26nl10rgffgahk7aka80p1m-nodejs-14.17.0 00a9nyyhwxisv4vc4rvwzp71nfip53x9-user-environment.drv 00m5h0pfzw2182qmyganlkaa9j4l2hps-vector-th-unbox-0.2.1.9.drv 010v6j5jjk2wpniznas31hbwvz1p1f5d-zapfding.r31835.tar.xz.drv 013sdi43bca33mnc3gn0v5r8lifrgcdj-hwdata-0.347.drv 01c3690lhmk0za0hnnh23n6mfgmiijpf-libdv-1.0.0.drv 01kc15hni6gff4z1p3y14v9f1395x2pf-python3.8-tap.py-3.0.drv
> The whole build system is pinned by on git commit. If it builds today, it will build tomorrow. No matter what.
If that commit is still available. This still doesn't answer the question of how I easily pin a version. The package versions in the post point to what amounts to a random package version.
And that's on top the fact that "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"
> Nix stores each package in its own path.
This is a part that I like.
Why wouldn't it be available? Nix packages are on github. [1]
> And that's on top the fact that "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"
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.
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/...
Maybe nix is not for you. I'm not well versed with nix packages and only use the basics.
Your answer on how to pin this package hasn't been answered good enough for you because it takes work to pin packages and it isn't as trivial as on ubuntu. To paraphrase it's a great place to live but not to visit.
Some of my friends are active in the NIX community. They mentioned that it was around as hard as learning haskell. One of them only grokked nix after he read nix pills [1].
I think nix has good concepts and in theory is the package manager I would like to use. In practice it isn't that.
Personally, I run ubuntu and use nix packages for three things:
- quickly test a program without needing to install it system wide via apt-get `nix-shell -p appname` - together with direnv for the dependencies of CPP projects I work on and - installing commandline tools packages
> Personally, I run ubuntu
What does Ubuntu have to do with it?
Here's a quote from the article:
--- start quote ---
Ditch your version manager
September 17, 2021 • 7 min read
You probably use a variety of tools to manage your Ruby, Node, Python, Elixir versions, such as rvm, rbenv, nvm, or asdf. They all work reasonably well, right?
Well, not quite.
...
My ideal dependency manager would allow me to specify each and every dependency that is required to work on my projects. It should be easily reproducible, declarative and easy to upgrade.
--- end quote ---
To this end, the author proposes to ditch rvm, rbenv, nvm etc. and go for nix.
Here's the entirety of what I need to do to pin my ruby version:
rvm install 2.1.1
rvm use 2.1.1
That is it.I've yet to see anything that approaches this in nix. We are talking about reproducible builds, aren't we?
I found the nixpkgs versions using this tool: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable...
You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays
What is "the same level"?
> You can pin ruby to exact version you want with https://nixos.wiki/wiki/Overlays
That page says: "Overlays provide a method to extend and change nixpkgs"
I don't want to change something. I want to simply pin a version. This is neither simple, nor scalable, nor maintainable (also here: https://news.ycombinator.com/item?id=28591202):
Overriding a version
self: super:
{
sl = super.sl.overrideAttrs (old: {
src = super.fetchFromGitHub {
owner = "mtoyoda";
repo = "sl";
rev = "923e7d7ebc5c1f009755bdeb789ac25658ccce03";
# If you don't know the hash, the first time, set:
# sha256 = "0000000000000000000000000000000000000000000000000000";
# then nix will fail the build with such an error message:
# hash mismatch in fixed-output derivation '/nix/store/m1ga09c0z1a6n7rj8ky3s31dpgalsn0n-source':
# wanted: sha256:0000000000000000000000000000000000000000000000000000
# got: sha256:173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4
sha256 = "173gxk0ymiw94glyjzjizp8bv8g72gwkjhacigd1an09jshdrjb4";
};
});
}Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do.
As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?
Not only me.
> That's because it's solving slightly different problems than package managers currently do.
We keep hearing this claim, and hardly any proof of that.
> As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?
1. Commit hashes are not versions
2. Hunting down every commit hash of every package to pin down the exact version is neither maintainable nor scalable
I believe flakes will make this a lot easier, but it's not quite here yet.
Somewhat, I guess? It will apparently let you write this:
{
inputs = {
home-manager.url = "github:nix-community/home-manager";
};
}
where you can manually point to a specific commit/branch for a tool.Better than nothing, I guess :)
I found the nixpkgs version using this tool: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable...