Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Let
network.pkgs
be optional.If
network.pkgs
is set, thennixpkgs.pkgs = mkDefault network.pkgs
.Introduce
network.lib
,network.runCommand
andnetwork.evalConfig
allowing for override of morph eval-machines internals.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 asnixpkgs.pkgs
, still honoringnixpkgs.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?