Having a completely deterministic per-project (directory) environment, no matter what language you use, is one of the best benefits of Nix. If you have 10 different Ruby/Elixir/Rust/Bash/etc. projects, you can have it set up whereby simply cd'ing into the directory (thanks to direnv integration) will set up a pure development environment, with the exact version of (say) Ruby ready to go, even with multiple different versions of Ruby between different projects, etc.
Every single language seems to have a half-assed tool to help do this sort of thing... asdf, virtualenv, etc. If you learn a little Nix, you can basically have a real solution that usurps all of these other ones, across all languages
how is this better than just using asdf where i can just put a `.tool-versions` file in the project and have it swap ruby+node+whatever to the appropriate versions?
In my Elixir app's case, the app was not deterministically reproducible using only asdf because it had underlying dependencies (a NIF, in this case VIPS) that required either C or Rust compilation at build time, and that in turn required another stack of dependencies with specific versions (which often broke the build), and even if that was all lined up, there are outside dependencies such as SSL libraries which can make or break builds when not using something like Nix (which gives you total control over every dependency). But the funny thing is that all I had to do was specify "vips" as an input, and since Nix already takes care of giving vips whatever IT needs to build correctly, it was basically a no-op to make this work with Nix.
Conceptually I love this idea. I love the idea of them being able to build AWS/GCP/VM images of the same thing even more. The place it falls down for me is that for it to be truly valuable everyone on the team needs to be bought in, and Nix is in my experience not the friendliest of tools. I have nasty images of the build breaking and everyone just being baffled by it, which is certainly an issue with Docker as well, but at least Docker is just running some shell commands during build.
Getting buy-in from your team can happen gradually; initially I think you'd only need 2 people with basic competence to get past most build difficulties (in order to avoid the "hit by a bus"/"vacation" problem), and the others can learn as those 2 go (and communicate how they fixed things). Docker certainly isn't just "running some shell commands"
https://nixcloud.io/tour/?id=1 < This one's a pretty cool interactive nix language tour that works by asking you to solve progressively more challenging problems and then validates the solution by actually running it- I love this approach to learning a language.
I assume folks downvoted this because they figured it was asking about Ruby or Bundler as upstream projects.
But looking at it from a perspective where Nixpkgs is the upstream: what does this introduce that would be unwelcome in Nixpkgs' bundlerEnv, or perhaps situated so it can share code with the existing implementations?
You don't necessarily have to know the Nix language upfront, but it helps (otherwise your eyes will glaze over in parts you'd otherwise grok right away). Honestly, it's not a terrible starting point. Nix has been described as "JSON with a different syntax, plus pure functions" which does come sort of close- It's not actually as complex as it looks at first.
There's a very cool interactive tutorial here which fit the way I like to learn pretty perfectly: https://nixcloud.io/tour/?id=1 It's an actual Nix interpreter running in the browser (thanks to emscripten) that validates your answers by actually evaluating them, through a series of progressively more difficult questions.
Unfortunately, nix is an extremely unfriendly thing in therms of documentation. It almost impossible to graps the meaning of its syntax, although people claim that nix is extremely useful. Nowadays the documentation (or a book) is the only concern that nix's team should be tackling.
There is a section called "Building a Docker image". Why do you need Docker if you are using Nix? It is like creating an environment inside another environment(?).
Every single language seems to have a half-assed tool to help do this sort of thing... asdf, virtualenv, etc. If you learn a little Nix, you can basically have a real solution that usurps all of these other ones, across all languages
reply