I lay the blame with the arcane and inconsistent design patterns in nixpkgs, and with the usability of the nix toolset. for instance, a number of times I've had

I lay the blame with the arcane and inconsistent design patterns in nixpkgs, and with the usability of the nix toolset. for instance, a number of times I've had packages fail to build due to 404s. I first tried to git clone nixpkgs and fix it there, but I had to set it up as a channel for that to work. next I wasted a day setting up an overlay, but I couldn't get the hang of the self: super: construct. finally I found that for this package it had a flag I could pass for a custom source package, but another package didn't have that, so I had to use overrideAttrs and worry about what builder phase that would apply to etc. etc. I shouldn't have needed to do this anyway - the nix team should run a mirror for external URLs, except there's no way I see to tell nix to use a mirror without editing all the URLs to point there. making mirroring bots or connectors to other package indexes, e.g. npm2nix, is a painful experience. it's also frustrating to have to inline bash scripts to build packages. one of the things Guix got right that Nix didn't, IMO, was using a capable language where implementing these patterns is easy, and using guile scheme instead of bash to actually build the packages. a Guix-like OS with the breadth of nixpkgs would take over the world - I hope both projects can learn from each other.