Before this commit, aarch64 users building the following configuration
would end up with an aarch64-linux builder, while after it, they get the
x86_64-linux builder they expect:
```nix
nix.linux-builder = {
enable = true;
package = pkgs.darwin.linux-builder-x86_64;
};
```
Before, in order to get an x86_64-linux builder, they would have needed
to use this configuration instead:
```nix
nix.linux-builder = {
enable = true;
config.nixpkgs.hostPlatform = "x86_64-linux";
systems = ["x86_64-linux"];
};
```
The reason for this is that the linux-builder module calls `override` on
the package option, and the `linux-builder-x86_64` package is also
defined using override:
```nix
linux-builder-x86_64 = linux-builder.override {
modules = [ { nixpkgs.hostPlatform = "x86_64-linux"; } ];
};
```
The module was effectively discarding the `nixpkgs.hostPlatform` option.
Example issue: https://github.com/NixOS/nixpkgs/issues/313784
This commit updates the nix.conf validation logic to accommodate
different versions of Nix. It introduces a conditional assignment
of the `showCommand` variable, which determines the appropriate
command to use based on the Nix version. For versions at least
"2.20pre", it uses "config show"; otherwise, it falls back to
"show-config". This change ensures compatibility across various
Nix releases.
This commit adds a protocol option for the `linux-builder` and defaults
it to `ssh-ng`. I have observed it needing this with the following:
``` sh
$ nix store ping --store ssh://linux-builder
Store URL: ssh://linux-builder
$ nix store ping --store ssh-ng://linux-builder
Store URL: ssh-ng://linux-builder
Version: 2.18.1
Trusted: 0
```
This seems to make the difference on whether or not Nix picks up
`linux-builder` as an available builder.
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 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.
This was
mkDefault { } // filterAttrs () x
which is interpreted as
(mkDefault { }) // (filterAttrs () x)
but the intention is
mkDefault ({ } // filterAttrs () x)
Resulting in lastModified, rev, etc. not being included. This is
essentially just bringing this clause up-to-date with the one from
NixOS.
