`mkEnableOption` wraps its argument in a complete sentence with a
terminating full stop; an additional newline will add an incorrect
space before the end of the sentence in the rendered documentation,
and any additional verbiage that doesn't fit into the form "Whether to
enable [...]." is also incorrect. In the latter case, the description
can be overridden manually.
These are the equivalents of the
NixOS options with the same name, introduced in
d3ac0938a7.
Allows running extra commands while building the system configuration
output, for example to add extra files into the output directory,
and passing arguments to the system builder's mkDerivation.
This is a big change that disentangles a lot of mistaken assumptions
about mixing multiple versions of Nixpkgs, treating external flake
inputs as gospel for the source of Nixpkgs and nix-darwin, etc.;
the end result should be much simpler conceptually, but it will be a
breaking change for anyone using `eval-config.nix` directly. Hopefully
that shouldn't be a big issue, as it is more of an internal API and
it's quite likely that existing uses may have been broken in the same
way the internal ones were.
It was previously easy to get into a state where your `lib` comes
from nix-darwin's `nixpkgs` input or a global channel and your
`pkgs` comes from another major version of Nixpkgs. This is pretty
fundamentally broken due to the coupling of `pkgs` to its corresponding
`lib`, but the brokenness was hidden much of the time until something
surfaced it. Now there is exactly one mandatory `lib` input to system
evaluation, and the handling of various additional options like `pkgs`
and `system` can be done modularly; maintaining backwards compatibility
with the previous calling convention is punted to the `default.nix`
and `lib.darwinSystem` entry points. `inputs` is no longer read by
nix-darwin or special in any way, merely a convention for user code,
and the argument is retained in the entry points only for backwards
compatibility.
All correct invocations of the entry points should keep working
after this change, and some previously-broken ones should be fixed
too. The documentation and template have been adjusted to show the
newly-recommended modular way of specifying various things, but no
deprecation warnings have been introduced yet by this change.
There is one potential, mostly cosmetic regression:
`system.nixpkgsRevision` and related options are less likely to be
set than before, in cases where it is not possible to determine the
origin of the package set. Setting `nixpkgs.source` explicitly will
make this work again, and I hope to look into sending changes upstream
to Nixpkgs to make `lib.trivial.revisionWithDefault` behave properly
under flakes, which would fix this regression and potentially allow
reducing some of the complexity.
Fixes: #669
We trust the version information from `nixpkgs.source` when `pkgs` was
constructed by the `nixpkgs` module or `nixpkgs.source` was explicitly
set by the configuration. Otherwise, we rely on Nixpkgs to report its
own version, which handles the same cases as the old logic and opens
the door to Nixpkgs automatically reporting the correct revision when
using flakes.
This is based on the current NixOS `nixpkgs` module, adjusted for the
nix-darwin context and without adding the options due for deprecation
in NixOS.
This gives us the ability to set the package set modularly through
`nixpkgs.pkgs` and builds up infrastructure for handling user-specified
Nixpkgs instantiations more robustly.
The cross-compilation options are currently not very useful due to
even Darwin->Darwin cross-compilation not being wholly functional
yet, but it looks feasible to build an `aarch64-darwin` system from
`x86_64-darwin` with some patching and it should be possible to make
cross-compilation more widely supported after the Darwin SDK situation
in Nixpkgs improves.
One casualty is the error for setting `nixpkgs.*` options when
overriding the package set. That could be ported over to this new
scheme, but it'd increase divergence with the NixOS module and reduce
cross-compatibility of configurations, so I lean towards adding it
upstream to NixOS if anything. (But if people want to keep it I can add
it back.)
This should be less brittle than the version-based check, although
arguably this kind of `lib.version` mismatch should break as early
as possible...
Fixes: #718
