This was very informative. I’ve been using Nix far longer than Julia and I have endured many battles with mkDerivation, never thinking to go one step deeper. I knew that it was a wrapper over a builtin derivation, but I never realised just how simple builtin derivations are to write, and how much fluff they remove from the process.
I can definitely empathise with the debugging approach - with Nix you kind of have to take a scattergun approach, search around randomly trying to find packages or solutions. I’ve since given up using search.nixos.org and now just grep the nixpkgs repository. Often the solution will be in a commented out piece of code saying “removed ugly hack”, then I learn from their solution and apply the ugly hack anyway. Because, you know.
> I’ve since given up using search.nixos.org and now just grep the nixpkgs repository.
I still use search.nixos.org as well, but this is the single biggest step anyone can take to massively level up with Nix. Nixpkgs is an incredibly valuable collection of examples, both of how to use Nix and of how to configure the upstream services that NixOS supports.
It might sound ugly, or overinvolved, or intimidating, but once you add the Nixpkgs codebase to your list of reference documents, many things become way faster and easier.
Great point! If you know what package you want to examine, these are both super handy.
Just because you want to peek at a package's build's source does not mean you have to go grepping blind through the repo. Better to be pointed directly to the right file by one of these tools!
I use the source link on the NixOS Package Search site on mobile all the time, when I want to refer myself or others to examples but I'm afk.
It would be helpful to teach people without so much being done by mkDerivation or other builders. While they provide value, they sometimes block learning. I like start with super simple example, if possible.
Grepping nixpkgs is what i do as well, but for functions specifically i found https://noogle.dev/ to be useful.
Same experience with mkDerivation as well - I personally have lots of hope for https://github.com/DavHau/drv-parts and similar projects to improve that situation :)
Love it! I've never actually used Nix, as I fell right into Guix, and it's really interesting to see how this all comes together without gexps to simplify evaluation orders and dependencies.
Great article! I think I knew most of it already but I’ve never seen all of it covered so succinctly and easy to understand!
I think in the case of Nix it is especially important to have a good grasp of the fundamentals so that you can verify your (possibly wrong) assumptions when troubleshooting a build failure, evaluation failure or when using the higher level constructs of nixpkgs.
And renaming of the component parts to clearly differentiate the OS from the shell from the package manager from... making the specifics more easily googlable in the process.
There is a large overlap of users who like using the Nix package manager, & of those who like using NixOS. -- I don't think any official documentation refers to 'NixOS' as 'Nix'. Maybe in some discussions, people are imprecise.
I think a sample sentence like "I love Nix! I use NixOS as my daily driver" doesn't really conflate the two too much.
I can definitely empathise with the debugging approach - with Nix you kind of have to take a scattergun approach, search around randomly trying to find packages or solutions. I’ve since given up using search.nixos.org and now just grep the nixpkgs repository. Often the solution will be in a commented out piece of code saying “removed ugly hack”, then I learn from their solution and apply the ugly hack anyway. Because, you know.
reply