[Nix-dev] Re: User environment hooks

[Ludovic Courtès]

Hi,

"Andres Loeh" <andres.loeh at googlemail.com>
writes:

> 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.

Well, the tip of the iceberg is visible at
$nix/corepkgs/buildenv/default.nix.  It wouldn't be difficult to modify
the builder in there to, e.g., look for `user-environment-hook' files in
the input store paths.

> 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:

I suppose the core in `corepkgs/buildenv' could be augmented to invoke a
user-provided function (when available), passing it the `system',
`derivations' and `manifests' arguments, along with a function that
actually does the derivation, if you see what I mean.  The
aforementioned file would become something along the lines of:

  {system, derivations, manifest}:

  let userBuild = getConfig [ "userEnvironment" "build" ] null;
      makeUserEnvironment = { system, derivations, manifests }:
        derivation { 
          name = "user-environment";
          system = system;
          builder = ./builder.pl;

          manifest = manifest;

          # !!! grmbl, need structured data for passing this in a clean way.
          paths = derivations;
          active = map (x: if x ? meta && x.meta ? active then x.meta.active else "true") derivations;
          priority = map (x: if x ? meta && x.meta ? priority then x.meta.priority else "5") derivations;
        }

  in
  if userBuild != null
  then (userBuild { inherit makeUserEnvironment system derivations manifest })
  else (makeUserEnvironment { inherit system derivations manifest })

The thing is, user-provided user-environment build functions could come
either from the end-user (e.g., in ~/.nixpkgs/config.nix), or from
Nixpkgs (as in the Info and TeXLive cases).

> 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.

Right, but in practice, we'd like this sort of things to work
out-of-the-box.

>> 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 agree on this.  :-)

> 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.

Hmm, interesting, but mapping it to the Nix language doesn't seem
obvious.

Thanks,
Ludo'.