Complex container values like `-array` have their own DSL which does not
allow specifying all data types. Instead of using the DSL use plist
fragments instead.
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 process was automated by [my fork of `nix-doc-munge`]; thanks
to @pennae for writing this tool! It automatically checks that the
resulting documentation doesn't change, although my fork loosens
this a little to ignore some irrelevant whitespace and typographical
differences.
As of this commit there is no DocBook remaining in the options
documentation.
You can play along at home if you want to reproduce this commit:
$ NIX_PATH=nixpkgs=flake:nixpkgs/c1bca7fe84c646cfd4ebf3482c0e6317a0b13f22 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run github:emilazy/nix-doc-munge/0a7190f600027bf7baf6cb7139e4d69ac2f51062 \
{} +
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge
These all use DocBook markup too complex for `nix-doc-munge` to handle,
have syntax that clashes with Markdown, or already contain Markdown
syntax that currently isn't rendering correctly.
Converting DocBook list syntax makes me think that maybe Markdown
isn't so bad after all.
These help `nix-munge-doc` automate more of the Markdown conversion
process. See the following nixpkgs commits for explanations of many
of these changes:
* 275a34e0d8
* 694d5b19d3
* f1d39b6d61
* 16102dce2f
I couldn't think of any particularly good way to format the
`system.defaults` breadcrumbs, so I just made them standalone
paragraphs. They weren't rendering correctly in DocBook anyway.
Currently, `system.patches` doesn't work because it will attempt to first detect if the patch has already been applied by checking if it can be applied in reverse.
However, when that happens, `patch` detects that the supplied patch is incorrectly reversed and attempts to ask the user if they want to "Ignore -R":
```
Unreversed (or previously applied) patch detected! Ignore -R? [y]
```
Because the output is piped to `/dev/null` the user will basically see nothing and `darwin-rebuild switch` will hang until the user presses "Enter" (possibly to check if the terminal is frozen). At which point, patch will ignore the --reverse and exit successfully, preventing the patch from being applied at all.
This change fixes that bug by using `--force` which tells patch that we know what we're doing and prevents it from prompting the user if they want to ignore `--reverse`.
Normally, the system region setting determines whether the clock uses
12- or 24-hour time. This flag allows users to override this setting and
use 24-hour time even if their region does not.
While the Nix store is almost always at `/nix/store`, we shouldn't
assume it to be. Checking only the trailing part of the link is less
exact but removes this bad assumption.
I also added a check for the symlink's contents when overwriting it to
more accurately check whether we own it and should replace it.
This PR supercedes #226.
So far application bundles were always linked to `~/Applications` or
`~/Applications/Nix Apps` if the former was an existing directory.
In nix-community/home-manager#1341 a conflict was found with suggested
new Home Manager behavior, where applications installed through Home
Manager would end up in `~/Applications/Home Manager Apps`. This was in
an attempt to make them discoverable through Spotlight but further
investigation suggest Spotlight does not pick up symlinked apps (details
in the issue).
However, there are other programs that expect to be able to write to
`~/Applications` so taking over the directory is unfortunate.
PR #226 dropped linking `~/Applications` and instead made sure the
directory exists so we can always link in `~/Applications/Nix Apps`.
After further discussion in #macos:nixos.org we came to the conclusion
that we shouldn't link applications to a user directory at all. Since we
manage packages for multiple users, application bundles should go in
`/Applications`.
Because previous code will likely leave a symlink at
`~/Applications/{,Nix Apps}`, which will become dangling once the path
it links to is garbage collected from the store we test to see if a link
exists and it conforms to the path we're expecting and if it does remove
it.
Programs like Steam add applications to ~/Applications and such.
This commit disables linking ~/Applications to nix-darwin Applications
in the /nix/store and makes nix-darwin use a subfolder within
~/Applications.
According to some investigation creating "role" accounts avoids
migration problems when upgrading to certain macOS versions, so create
the build users to match that definition and remove the old ones if
present.
Role accounts require name starting with _ and UID in 200-400 range
