The main points in short: 1. It shows what is going to change in a human-readable format (`dry-run'). In particular you get a chance to check which one-off install you might want to keep.
2. It allows to include store-path packages. This ability is useful if nix-env -r would remove a version that you want to keep. On 03/01/2016 08:58 PM, Luca Bruno wrote: > How does it differ from this simple nix-env > usage? > https://nixos.org/wiki/FAQ#How_can_I_manage_software_with_nix-env_like_with_configuration.nix.3F > > On Tue, Mar 1, 2016 at 8:51 PM, Lu Fennell <[email protected] > <mailto:[email protected]>> wrote: > > Hi Nix-dev, > > For quite some time now I'm using a glorified Haskell script that I call > "nix-env-rebuild" to manage my user profile "declaratively" (i.e., > by specifying the list of installed packages in a file). Triggered by > the discussion on the new Nix UI, I decided to do some polishing and > release nix-env-rebuild on github: > > https://github.com/lu-fennell/nix-env-rebuild > > Features: > - Upfront configuration of a profile through a config file > (~/.nixpkgs/packages.nix) similar to the "systemPackages" attribute. > - Commands similar to "nixos-rebuild": dry-run, build, switch > - Shows a summary of how the current profile differs from the > "declared" one. > - "nix-env -i .." effectively becomes a one-shot install action > (e.g., for test-driving packages). Running "nix-env-rebuild dry-run" > shows which packages where added by "nix-env -i" (giving you a > chance to add them to your package list). Running > "nix-env-rebuild switch" removes those one-shot packages. > - The packages of "packages.nix" can be overridden or extended with > concrete store paths (in a second configuration file, > ~/.nixpkgs/store-path-install-list.txt). This is useful e.g. for > blocking undesired upgrades or preventing expensive rebuilds. > > So if you are interested in this style of (user)-package management, I > invite you to give nix-env-rebuild a try. I'm eagerly awaiting your > comments and bug reports :) > > In particular I am interested in discussing the relation to the "nix > install" parts of Eelco's new UI proposal: It seems like the proposal > tries to support "declarative package management" through "nix install > -d" and "nix rebuild". I think that an approach akin to > nix-env-rebuild is a better fit, mainly for two reasons. > > 1. I think upfront configuration is more "declarative" in nature than > "nix install -d", which is an imperative operation. > > 2. One-shot installs, in the sense outlined above, seem difficult in > "nix install"/"nix install -d"/"nix rebuild": Doing a > > NIX_PATH=some/very/unstable/channel nix install bleeding-edge-package > > would rebuild all "declarative" packages against > some/very/unstable/channel, although I might just want to > test-drive "bleeding-edge-package". > > Perhaps I am wrong thinking "nix install -d" is supposed support > "declarative package management"? (in this case I think the > "-d"-option's is name is quite misleading) > > But if not, I am curious to know if you concur with my observations > and how your ideas of "declarative user package management" may differ > from mine. > > Best regards, > Lu > _______________________________________________ > nix-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > > -- > NixOS Linux <http://nixos.org> _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
