mobile-nixos/lib/eval-with-configuration.nix

# This is a shim that calls `evalWithConfiguration` automatically, with
# some additional helpers.
# This replaces the previously quite un-hermetic `default.nix` inclusion.
# This is meant for use internally by Mobile NixOS, the interface here
# should not be assumed to be *stable*.
{
  pkgs ? import <nixpkgs> {}
  # The identifier of the device this should be built for.
  # (This gets massaged later on)
, device ? null
, configuration
  # Internally used to tack on configuration by release.nix
, additionalConfiguration ? {}
, additionalHelpInstructions ? ""
}:
let
  inherit (pkgs.lib) optionalString strings;
  inherit (strings) concatStringsSep stringAsChars;

  # Either use:
  #   The given `device`.
  #   The environment variable.
  final_device =
    if device != null then device
    else throw "Please provide a device name using e.g. `--argstr device $DEVICE`."
  ;

  inherit (import ./release-tools.nix { inherit pkgs; }) evalWith;

  # The "default" eval.
  eval = evalWith {
    device = final_device;
    modules = configuration;
    inherit additionalConfiguration;
  };

  # Makes a mostly useless header.
  # This is mainly useful for batch evals.
  header = str:
    let
      str' = "* ${str} *";
      line = stringAsChars (x: "*") str';
    in
    builtins.trace (concatStringsSep "\ntrace: " [line str' line])
  ;
in
  (
    # Don't break if `device` is not set.
    if device == null then (id: id) else
    if device ? special
    then header "Evaluating: ${device.name}"
    else if (builtins.tryEval (builtins.isPath device && builtins.pathExists device)).value
    then header "Evaluating device from path: ${toString device}"
    else header "Evaluating device: ${device}"
  )
{
  # The build artifacts from the modules system.
  inherit (eval.config.system) build;

  # The evaluated config
  inherit (eval) config;

  # The final pkgs set, usable as -A pkgs.[...] on the CLI.
  inherit (eval) pkgs;

  # The whole (default) eval
  inherit eval;

  # Evaluating this whole set is counter-productive.
  # It'll put a *bunch* of build products from the misc. inherits we added.

  # (We're also using `device` to force the other throw to happen first.)
  # TODO : We may want to produce an internal list of available outputs, so that
  #        each platform can document what it makes available. This would allow
  #        the message to be more user-friendly by displaying a choice.
  #        Something like `config.mobile.build.proposedOutputs` as a list of pairs [ "outputName" "description" ].
  __please-fail = throw ''
    Cannot directly build for ${final_device}...

    Building this whole set is counter-productive, and not likely to be what
    is desired.
    ${optionalString (additionalHelpInstructions != "") "\n"}${additionalHelpInstructions}
    *************************************************
    * Please also read your device's documentation. *
    *      It may contain further usage notes.      *
    *************************************************
  '';
}