[Nix-dev] User environment hooks

[Andres Loeh]

Hi.

One way to look at nix-env is that it implicitly constructs a Nix
derivation (called the user environment) and builds it in the store.
Unfortunately, we never quite see the Nix expression that belongs to
the derivation -- it really is implicit.

However, we can think about it as something like a function, lets
call it buildUserEnvironment, applied to a list of arguments that
typically are attribute names from the nixpkgs collection:

let

  pkgs = import ...nixpkgs...;

in

  with pkgs;
  buildEnvironment
    [
      # all the packages I'm interested in
      git
      ghc
      texLive
      firefox
      ...
    ];

Now, calling "nix-env -iA name" essentially adds name to that list
of packages. Editing the list by hand is slightly less comfortable,
but would also be more flexible, because we cannot just name plain
attribute names, but also make our own compositions such as

      (texLiveWith [ cmSuper ])

Sorry for taking so long with preliminaries, but let's get back
to your mail:

>> I know I asked and thought about this user environment hook before as well,
>> but the longer I work with NixOS, the less I think it's in the spirit of the
>> system. Almost all situations I have encountered can be solved with
>> functions that do the work, and having functions assigned to it makes the
>> compositions of packages clear, whereas dynamic composition in a user
>> profile is terribly fragile.
>
> Can you propose a way of handling the GNU Info case?  The goal is to
> have a `dir' file that reflects the Info files available to the user.

If you have the buildEnvironment function explicit, there's a clean way
to add extra functionality to it -- namely to use another function:

  buildEnvironmentWithInfoPages

This builds the environment, scans the resulting files for info pages,
and produces the index. Every user can enable or disable that function.

>> I think it is wrong of NixOS to give an UI advantage to packages that are
>> composed for you already in all-packages.nix (the advantage being that they
>> can easily be queried and installed by the package name rather than the Nix
>> attribute name). We should encourage users to compose their own packages,
>> because that's part of the strength of NixOS. I have shown in my previous mail
>> that often, it is not that hard -- you just have to write a little Nix program
>> in your home directory. On the other hand, it's still much harder than using
>> nix-env -i directly, and we should think about ways to simplify this approach.
>
> That's true, but OTOH, many people expect to be able to do "nix-env -i"
> in the vast majority of cases, just like they used to do "apt-get
> install".  Anything beyond that is bound to be considered by many users
> as too complex for the task at hand, too intrusive, and/or
> counter-intuitive (why would some packages be installable and listable
> by `nix-env' while others aren't?).
>
> Thus, I think we should strive to handle common cases in a way that
> doesn't require any user intervention beyond "nix-env -i".

I have a different viewpoint. I also think that editing Nix programs is too
difficult for the majority of users. On the other hand, I don't think that
nix-env -i as it currently is should be the maximum that's possible. We need
to think about ways of improving nix-env -i's interface in order to be more
flexible, and I like to think about some explicit Nix expression similar to
the one above in order to be able to talk about what exactly nix-env commands
mean.

Some more dreaming: why does the package namespace have to be flat? Assume
we could do

  nix-env -qa 'ghc-6.8.3/*'

or

  nix-env -qa 'texlive/*'

to get a list of all Haskell libraries or all TeXLive extensions.

Packages that conceptually "belong" to another package such
as Haskell libraries, TeXLive extensions, or Firefox plugins,
could be getting names underneath the package name they belong
to. So you could say

  nix-env -i texlive/beamer

in order to get your texLive installation extended with the beamer function.
In terms of the implicit Nix expression, it would mean that your entry
entry

  (texLiveWith [ cmSuper ])

is updated to

  (texLiveWith [ cmSuper beamer ])

This might be a way to allow your own compositions while still
staying relatively user friendly.

Cheers,
  Andres