3 ms·
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software Correct. > It's a reasonable tradeoff th
by jolux 3y ago
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
- rgoulter 3y ago> In what universe is it reasonable to make package consumers write software... Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`). I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile. With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is. In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs. > Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder. Yeah, Nix is much more difficult to use than other tools. Nix's UX is one where you pay a big cost upfront in order to save on effort later. e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.