Proposal: Changes to eval-machines

[johanot]

Motivation

#67 and #70 did nice groundwork for per-machine nixpkgs args.

However the various changes have lead to a situation where nixpkgs and sometimes nixpkgs overlays get evaluated more than once, due to the modifications and merging of nixpkgs args morph eval-machines currently does. These cases are difficult to debug and non-trivial to fix, due to the custom way that morph merges and modifies the nixpkgs.* options while evaluating.

Also, it is sometimes just non-intuitive how nixpkgs args and nixpkgs options work with morph and users become unsure whether the latter work as described in the NixOS manual, when using morph.

In short, we want to not evaluate nixpkgs or overlays more than once - unless we have to. And we want to preserve the expected behavior of all the available nixpkgs.* options.

Proposed new behavior

1. Let network.pkgs be optional.

2. If network.pkgs is set, then nixpkgs.pkgs = mkDefault network.pkgs.

3. Introduce network.lib, network.runCommand and network.evalConfig allowing for override of morph eval-machines internals.

4. Get lib, runCommand and evalConfig from the network attrset, if unset then from network.pkgs, if unset then fallback to <nixpkgs>.

The consequence of 1 and 2, is that network.pkgs works exactly as nixpkgs.pkgs, still honoring nixpkgs.overlays, but disabling all other nixpkgs options.

3 and 4 allows for injection of all internal morph build dependencies, moreover preventing evaluation of multiple nixpkgs sets, even when network.pkgs is unset.

Feedback

@Shados I'd much appreciate your feedback on this. Especially, how does this solution affect cross-compilation with morph from your point of view? And what are your thoughts in general?

[johanot]

@Shados will you get a chance to look at this during the coming week? (no pressure) :-) Don't know who else could have an opinion here. @delroth ?

[Shados]

Huh. Weirdly I didn't get a notification for the initial ping. I'm probably not going to have time to really have a play with this, but it basically looks OK; people can still manually merge things if they want. I'm not using morph with any cross-compiled systems, so don't really have anything for you on that front.

[johanot]

@flokli This is not a requirement for releasing at all (and I haven't forgotten you) :-). But.. Perhaps you have an opinion about this change as well? Feedback is much appreciated.

[flokli]

@johanot LGTM in general, but I haven't yet wrapped my head around whether this makes cross more difficult or not. I'll pass that question to @lheckemann ;-)

[lheckemann]

I'm not familiar with morph at all, haven't tried it before. But this looks to me as if it would make cross easier by introducing more flexibility.