2 ms·
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 diffe
by pmarreck 4y ago
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
- masukomi 4y agohow 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? (honest question) https://asdf-vm.com/ https://asdf-vm.com/
- pmarreck 4y agoHere's a good answer to that question (scroll down for comparison to asdf): https://medium.com/@ejpcmac/about-using-nix-in-my-development-workflow-12422a1f2f4c https://medium.com/@ejpcmac/about-using-nix-in-my-developmen... 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. Given the fact that you can output a Docker from a nix recipe/derivation https://thewagner.net/blog/2021/02/25/building-container-images-with-nix/ https://thewagner.net/blog/2021/02/25/building-container-ima... , it also supersedes Docker IMHO
- jon-wood 4y agoConceptually 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.
- pmarreck 4y agoGetting 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" Here's a link to one of a few blogposts about building container images with nix: https://thewagner.net/blog/2021/02/25/building-container-images-with-nix/ https://thewagner.net/blog/2021/02/25/building-container-ima... Here's a few good links to get started: https://nix.dev/ https://nix.dev/ https://nixcloud.io/tour/?id=1 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.