3 ms·

Yes this. I tried this a few times but always ended in me banging against some esoteric issue. For example I tried to nixify a project I had which needs ruby an

Yes this. I tried this a few times but always ended in me banging against some esoteric issue. For example I tried to nixify a project I had which needs ruby and node. If you think you can spin up any version of ruby you are mistaken. The project removes older versions from time to time. The wrapper to fetch the correct gems from nix to setup the nix-env had really hard problems when gems or npm packages started their own native builds. I’m a huge fan of the project and will give it a try again at one point. But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix.

_huayra_ 5y ago
> But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix. I think one can do this separately, e.g. run NixOS for the host OS and then do LFS or Gentoo or Arch in a VM where you can easily blow things up and revert to a prior snapshot. Also, flakes takes care of the channels shenanigans by pinning input package versions. The hardest thing about Nix is that there is very little in the way of "beginner to intermediate" documentation. There is a huge gap between tutorials about just tweaking configuration.nix and a bit a people who have insanely abstract / modularized configs. The key insight for me was that although they sell the "it's a lazily-evaluated language" thing really hard, at the end of the day there are a few things forcing side effects: - There are certain key attributes that nix will call forceAttrs on (in the interpreter). You can think of these as the "roots" that will act as a starting point for evaluating all other attributes as needed. This is the stuff you usually see like nixosConfigurations, shell, etc. The sad part is that you really have to read the C++ source to understand this it seems. - At the "bottom", there are a bunch of things built in to write to files in the sandboxed result/ directory, but there are also these monstrous bash scripts to do a lot of the heavy lifting, e.g. the mkDerivation one. It's important to read over these scripts to understand what's being written. I've found this youtube series [0] to be a good way to figure out how to go from beginner to intermediate. [0] https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac75v-x6EzNzZq- https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac7...
- larusso 5y ago
  Thanks for the resources! I switched from macOS to linux for my personal machine last summer. I played around with nix on some machines before and also used nix-pkg on macOS but ran into issues. There is a great community behind it and I read a lot about nix (the language) etc. My decision to go with arch was mainly practical. I don't want a huge desktop etc. I wanted to see what gnome etc actually automate for me. I have already a way better understanding what kind of features which I normally take for granted coming from macOS are not part in a base system. I will give it a go again when I have time as I like the declaritive nature of nixOS. edit spelling

_huayra_ 5y ago

> But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix. I think one can do this separately, e.g. run NixOS for the host OS and then do LFS or Gentoo or Arch in a VM where you can easily blow things up and revert to a prior snapshot. Also, flakes takes care of the channels shenanigans by pinning input package versions. The hardest thing about Nix is that there is very little in the way of "beginner to intermediate" documentation. There is a huge gap between tutorials about just tweaking configuration.nix and a bit a people who have insanely abstract / modularized configs. The key insight for me was that although they sell the "it's a lazily-evaluated language" thing really hard, at the end of the day there are a few things forcing side effects: - There are certain key attributes that nix will call forceAttrs on (in the interpreter). You can think of these as the "roots" that will act as a starting point for evaluating all other attributes as needed. This is the stuff you usually see like nixosConfigurations, shell, etc. The sad part is that you really have to read the C++ source to understand this it seems. - At the "bottom", there are a bunch of things built in to write to files in the sandboxed result/ directory, but there are also these monstrous bash scripts to do a lot of the heavy lifting, e.g. the mkDerivation one. It's important to read over these scripts to understand what's being written. I've found this youtube series [0] to be a good way to figure out how to go from beginner to intermediate. [0] https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac75v-x6EzNzZq- https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac7...

larusso 5y ago
Thanks for the resources! I switched from macOS to linux for my personal machine last summer. I played around with nix on some machines before and also used nix-pkg on macOS but ran into issues. There is a great community behind it and I read a lot about nix (the language) etc. My decision to go with arch was mainly practical. I don't want a huge desktop etc. I wanted to see what gnome etc actually automate for me. I have already a way better understanding what kind of features which I normally take for granted coming from macOS are not part in a base system. I will give it a go again when I have time as I like the declaritive nature of nixOS. edit spelling