4 ms·

I disagree with "don't use nix-env --install; use <much harder thing> instead". I see "nix-env --install" as a gateway drug to using Nix. It's effortless, and

I disagree with "don't use nix-env --install; use <much harder thing> instead". I see "nix-env --install" as a gateway drug to using Nix. It's effortless, and already easy to see benefits from using Nix (like you can easily get the same set of packages on different OSs). Rather, it's worth explaining why it's bad to use. The footgun I ran into was that I'd caused a messy state by installing something and forgetting I'd installed it. Maybe nix flakes and home-manager and nix-darwin are really cool.. but they're also much harder to use, and surely overwhelming for someone who just wants a way to install packages. I think it's like telling someone to learn Kubernetes when they're wondering how to serve the website they wrote. -- I think it's easier to appreciate these once you've gotten your feet wet with nix.

pxc 5y ago
You never want `nix-env --install` without it being `nix-env --install --attr`, though, because `nix-env -i` is like a billion times slower than `nix-env -iA`, and that gives people a really bad first impression. But yeah I agree, it's fine to use `nix-env -iA <package>` or whatever. It's fine when you're getting started, and it's fine for a slightly more persistent way of trying things out than `nix-shell`.
chriswarbo 5y ago
> Rather, it's worth explaining why it's bad to use. My biggest problem is that it's not version-controlled. I don't use home-manager, and (still) haven't looked into Nix flakes. Instead, I put `export PATH="/path/to/my/repo/result/bin:$PATH"` in my ~/.bashrc, and inside that repo I have a default.nix file: buildEnv { name = "my-packages"; paths = [ foo bar baz ... ]; } Running `nix-build` will update the result/bin symlink to point at the new applications.