4 ms·
This is why I manage every nontrivial project I do nowadays with Nix (Haskell, Go, Python, C & C++, bash ..anything) Everything is pinned to exact source revis
by whateveracct 7y ago
This is why I manage every nontrivial project I do nowadays with Nix (Haskell, Go, Python, C & C++, bash ..anything)
Everything is pinned to exact source revisions. You can be relatively sure to be able to git clone and nix-shell and be off to the races.
You can even go the extra mile and provide working editor integration in your nix-shell (especially easy with emacs). So you can enable anyone to git clone, nix-shell, and open a working editor.
The biggest downside is becoming proficient in Nix isn't easy or even straightforward.
- abathur 7y agoDitto, roughly.
- silviogutierrez 7y agoAgreed. Super painful to learn and still learning, but once it clicks, it's totally worth it. Amazing tool. Occasionally I still run into weird non-deterministic issues with builds, though: https://github.com/NixOS/nixpkgs/issues/71178 https://github.com/NixOS/nixpkgs/issues/71178 You'd think "pinning" a python version + channel would avoid this.
- s_kilk 7y ago> Everything is pinned to exact source revisions. While you're here, how do you do this with nix-pkgs? I looked into using nixos for nodejs deployments recently, and was amazed to find that the versions of node in the nix-pkgs repo are just pinned to X.Y.0 releases, with no discernable way to update to a bugfix release after .0 , so... I don't see how this could possibly be used for production deployments? https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=nodejs https://nixos.org/nixos/packages.html?channel=nixpkgs-unstab... What I really want is to be able to tell nix to give me nodejs at version 10.16.3 and have it do the right thing every time. I'm happy to be wrong on any of this.
- huevo5050 7y agoI think its a coincidence. Check nodejs commit history: https://github.com/NixOS/nixpkgs/commits/f3282c8d1e0ce6ba5d9f6aeddcfad51d879c7a4a/pkgs/development/web/nodejs https://github.com/NixOS/nixpkgs/commits/f3282c8d1e0ce6ba5d9... there are minor versions also
- s_kilk 7y agoRight, so if I'm understanding correctly, I'd need to pin the whole nix-pkgs system to the particular git revision which contains the version I need?
- huevo5050 7y agoThat's it, also you can cherry pick different software from different git revisions.
- silviogutierrez 7y agoDo you have any public examples of doing this? Or docs? Closest I found was to pin the nix-channel entirely, but not different components to different versions.
- soraminazuki 7y agoYou could do something like: let pinnedPkgs = import (builtins.fetchTarball {...}) {}; node = pinnedPkgs.nodejs-10_x; to refer to a specific version of node. https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs
- silviogutierrez 7y agoThanks that helps. I've mostly stuck to nix-shell -p foo bar baz to setup my environments. It's holding me back and I should pull the trigger on a shell.nix file, just gotta learn the language.
- soraminazuki 7y agoWhile the nix package manager supports the coexistence of multiple versions of a package, the nixpkgs package collection does not contain every single versions of every package. However, it does make it very easy to refer to past versions of a package by importing package specifications from an older version of nixpkgs. I think this is a reasonable choice, considering that the main purpose of nixpkgs is to provide packages for the NixOS distribution. It's impossible to actively maintain every single version of every package.
- shpx 7y agoHow do you specify Python dependencies and their versions in Nix?
- soraminazuki 7y agoA quick and dirty way would be: $ nix run "(import <nixpkgs> {}).python37.withPackages([ pandas statsmodels ])" This would drop you into a shell with Python 3.7, pandas, and statsmodels installed. For more complex use cases, you should specify your dependencies in a shell.nix file or write your own nix package.
- whateveracct 7y agoAnd then to expand, if you wish to pin one of those packages to a specific rev, the easiest way is to create an "overlay" (it's a Nix design pattern) that you apply to nixpkgs to override whatever version is in your nixpkgs version.