8 ms·

I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them w

• siraben 6y ago
  FYI nix-env operations are atomic and can be rolled back instantly, including upgrades. $ nix-env --rollback > The suggestion in the github issue was to instead use an unofficial third party package for basic package management. Specifically the suggestion is referring to home-manager, which is community supported (being in nix-community) and is the recommended way to install packages rather than imperatively doing it with nix-env.
  • danieldk 6y ago
    the recommended way to install packages rather than imperatively doing it with nix-env The problem is: recommended by whom? The Nix Manual presents nix-env as the main way to install Nix packages. So, as long as the manual centers around nix-env, newcomers will try to use nix-env and get bitten by it. The same is true for the NixOS Manual, it suggests that people install packages with nix-env before talking about declarative package management. Also, I love home-manager, but it is perhaps too much for people who just want to dabble in Nix a bit. It would be nice if a simpler declarative way of managing packages was presented first. Perhaps surprisingly, another way is documented but it is deep in the nixpkgs manual: https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
    • takeda 6y ago
      It's recommended by people who used Nix for a while. I have a different opinion myself though. While I don't use nix-env anymore I think it is important because serves as a bridge between nix and what people are typically expecting. I think nix-env syntax should be improved to be similar what you expect with other package managers though. Once you understand how nix operates you can then stop using nix-env. I personally use nix for development. For every project I define the whole environment including all tools I need for development. This ensures that if someone needs to work on my project can get the same dev environment. If you add a tool like direnv to the mix it makes the experience much, much better, because then environment is automatically set up as soon as you enter the project directory.
• Shoue 6y ago
  I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.
  • chaorace 6y ago
    Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.
    • tnzm 6y ago
      I don't use nix-env or home-manager. On my NixOS workstation everything (outside of nix-shells) is installed via environment.systemPackages. And I do wish there was an easy way to add stuff to install packages without rebuilding the whole system - I guess that's what nix-env is for but if I went with that I would the "single editable config file that you can put in VCS" aspect. I think nix-env uses profiles, which are implemented collection of symlinks to the Nix store - guess I could still version those...?
      • danieldk 6y ago
        https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
      • chriswarbo 6y ago
        You can define a package that contains a bunch of other things, e.g. I use packages like 'devCli', 'netGui', etc. (I actually put these in my systemPackages on NixOS and nix-darwin, but they would also work with nix-env) http://chriswarbo.net/git/nix-config/git/branches/master/overrides/metaPackages.nix.raw.html http://chriswarbo.net/git/nix-config/git/branches/master/ove...
    • otabdeveloper4 6y ago
• domenkozar 6y ago
  That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html#searching-package-attribute-names https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.
  • oblio 6y ago
    Now, don't get me wrong, I don't have a horse in this race. But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created. The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI. This seems like a basic QA fail, I wouldn't want anything like this within 100 km of any production environment I'm working on. I imagine Nix is underfunded, but few projects come back from stuff like this. If they can't get their stuff together in almost 2 decades, who will ever trust them that they ever will?
    • catern 6y ago
      nix-env (including nix-env -u) is purely a user-facing UI helper for new users. One would never use it in production, or even for development, even when it was first released; it's only ever been for new user onboarding. So it's a bit low priority, since it has no production impact and experienced users don't use it...
      • oblio 6y ago
        Today's new users are tomorrow's experienced users. I guess it depends on what Nix wants, if it wants to remain a niche system, then things are good as-is. Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.
        • danieldk 6y ago
          Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things. I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn [1]. Given that flakes are a large change, I'd expect (but maybe I am wrong) that there will be a new RFC. At any rate, I would be surprised if the new CLI with flakes are close to release. [1] https://github.com/NixOS/rfcs/pull/49 https://github.com/NixOS/rfcs/pull/49
• mitchmindtree 6y ago
  Yeah, I would really like to see `nix-env -i` recommended far less often, or at least with the caveat that this should only be for testing packages at the most. I still haven't found a good use case for it personally. One of the big wins for Nix is its declarative nature (especially for reproducibility) and installing packages in an imperative manner like this just seems to put folks back in the same position as using pacman or apt-get. Please correct me if I'm wrong Nix-ers. Having used NixOS as the main OS on my personal laptop for the past year or two (and loving it), I've only used `nix-env -i` to install a package once, and immediately regretted it after trying to add a different version of the same package to my main configuration files. This resulted in a conflict, which from memory required me to force reinstall the package again via `nix-env` but specify a lower priority so that it could be replaced automatically when enabling the package via my configuration files... A really strange experience that re-affirmed that nix-env is at least not for me. For testing packages, I would always recommend `nix-shell -p <package>` as a preferred option. Just type `exit` and then you've left the shell, it's no longer in your PATH and there's no risk of conflicts. It sucks that you ran into this, but also totally understandable. I think generally the community would consider the nix-env approach of installing and updating packakges an anti-pattern these days, but this certainly isn't obvious when reading through the docs.
  • mason55 6y ago
    Yeah I’ve been running Nix on a home server for a couple years and using home manager on my MBP for just as long. The biggest challenge to learning has been all the examples that use nix-env -i.
  • Izkata 6y ago
    > and installing packages in an imperative manner like this just seems to put folks back in the same position as using pacman or apt-get. Please correct me if I'm wrong Nix-ers. It being similar to the other commands means we can use nix almost no learning curve, only having to know the equivalent commands. It's the beginner's interface, allowing you to get things done right away, and letting you postpone the complexity until you have need for the features/stability it provides. For example, I originally started using nix because I needed a Java version not in Ubuntu's repo, and being able to say "just install it" instead of having to learn a whole new specification language is a massive benefit.
• Ericson2314 6y ago
  Well, that's bad. `-u` is bad, and that the cross compilation suffix somehow went after the version is also bad.
• fishywang 6y ago
  I'm the one filing that bug :) Before this bug I was running nixpkgs on top of all the Debian machines I'm using (including crostini vms on chromeos devices), mainly as a package manager to mange and keep up-to-date on things outside of debian's apt ecosystem (firefox, thunderbird, go, pipx, etc.). After this bug I removed nixpkgs from all of them. While I agree that nixpkg is great for declarative use cases others mentioned, and also it's very useful to try something temporarily (e.g. `nix-env -i something`, do things, then `nix-env --rollback`), those are not my main use cases (while at least not for my debian machines), and my main use case of it is broken because of that bug. I even recommended nixpkgs as a better alternative to homebrew to my friends using mac, I guess that's not really true any more. Now I keep up-to-date to things not in apt-ecosystem by subscribing to releases on github :(