[Nix-dev] Re: User environment hooks

[Andres Loeh]

Hi again.

On Fri, Oct 10, 2008 at 9:13 PM, Ludovic Courtès <ludo at gnu.org> wrote:

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

Well, there are not so many issues that are global like info pages.
Local modifications (such as TeXLive) can easily be handled locally,
i.e., the builder doesn't have to be changed completely, we just have
to compose TeXLive with its packages as the current solution does.

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

For this particular case, just make it the default.

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

The above already outlines a mapping to the Nix language. I completely
agree that this is far from a formal definition (hence the "dreaming"
part). However, if there's a consensus that this functionality were
a good thing, I would think about it.

Cheers,
  Andres