4 ms·

Yes people often blame the Nix langauge when they should blame Nixpkgs. I needs some more refactoring than we've been able to give it (though thankfully we've b

Yes people often blame the Nix langauge when they should blame Nixpkgs. I needs some more refactoring than we've been able to give it (though thankfully we've been able to give a lot of refactoring in absolute terms). I think static types what's needed to get us over the hill on this one.

sterlind 7y ago
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.
- Ericson2314 7y ago
  > mirrors Indeed it is a problem. I hope we will soon solve it. > instead of bash Totally agreed bash needs to go. I was thinking lua for sake of also supporting Windows.

sterlind 7y ago

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.

Ericson2314 7y ago
> mirrors Indeed it is a problem. I hope we will soon solve it. > instead of bash Totally agreed bash needs to go. I was thinking lua for sake of also supporting Windows.