[Nix-dev] Announcing "nix-env-rebuild" (and some comment on "nix install -d")

[Lu Fennell]

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 <lu-fennell at startmail.com
> <mailto:lu-fennell at startmail.com>> 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
>     nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>     http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 
> 
> 
> 
> -- 
> NixOS Linux <http://nixos.org>