3 ms·

Last week I had a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore. [1] See that `rev` line in the sourc

Last week I had a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore. [1] 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 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

dmitriid 5y ago
> a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore > 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.
- rvanlaar 5y ago
  > If that commit is still available. 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]https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
  - dmitriid 5y ago
    > 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/ruby-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
    - rvanlaar 5y ago
      Hey, 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 [1] https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/

dmitriid 5y ago

> a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore > 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.

rvanlaar 5y ago
> If that commit is still available. 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]https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
- dmitriid 5y ago
  > 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/ruby-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
  - rvanlaar 5y ago
    Hey, 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 [1] https://nixos.org/guides/nix-pills/ https://nixos.org/guides/nix-pills/