I chose not to do nixos.{config, options} because that would make it
look too much like a configuration object, which it is not.
A configuration object I would define as for example the result of
calling NixOS, an attrset with `_type = "configuration";`.
Recreating a configuration object without evalModules is quite
feasible but not guaranteed to be correct, and not maintainable.
skipping heading levels (eg from # to ###, or starting at ###) is legal
in pandoc, but not in nixos-render-docs. pandoc acts as though section
levels *were* consecutive, nixos-render-docs prefers to tell people not
to do that kind of thing because it can make documents more fragile.
without stable ids on headings we cannot generate stable links to these
headings. nrd complains about this, but the current docbook workflow
does not.
a few generated ids remain, mostly in examples and footnotes. most of
the examples are generated by nixdoc (which has since gained MD export
functions, and the MD export does generate IDs).
This is preferable because it prevents things like disk corruption (requiring the user to delete the disk image when starting up) that I consistently ran into.
The trailing `'` was included by mistake and is not supposed
to be there:
```ShellSession
$ base64 -w0 /etc/ssh/ssh_host_ed25519_key.pub
c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUpCV2N4Yi9CbGFxdDFhdU90RStGOFFVV3JVb3RpQzVxQkorVXVFV2RWQ2Igcm9vdEBuaXhvcwo=
```
The reason it did not cause issues before is because
Nix ignores everything after the `=`:
3dbf9b5af5/src/libutil/util.cc (L1539-L1540)
… so it's harmless but still worth fixing.
When I designed `mkShell`, I didn't have a good idea of what the output
should look like and so decided to make the build fail. In practice,
this causes quite a bit of confusion and complications because now the
shell cannot be part of a normal package set without failing the CI as
well.
This commit changes that build phase to record all the build inputs in a
file. That way it becomes possible to build it, makes sure that all the
build inputs get built as well, and also can be used as a GC root.
(by applying the same trick as #95536).
The documentation has also been improved to better describe what mkShell
does and how to use it.
The attributes got renamed in PR #126440 and in some places this caused
evaluation errors, e.g. the tarball job was saying (locally)
> attribute 'alsaUtils' missing, at /build/source/nixos/modules/services/audio/alsa.nix:6:4
and I suspect that trunk-combined jobset's failure to evaluate was also caused.
The distinction between the inputs doesn't really make sense in the
mkShell context. Technically speaking, we should be using the
nativeBuildInputs most of the time.
So in order to make this function more beginner-friendly, add "packages"
as an attribute, that maps to nativeBuildInputs.
This commit also updates all the uses in nixpkgs.
In my opinion Functions should only contain pure functions. These are
both meant to provide derivations so I put them under Builders. Don't
know exactly *where* to put them so "special" it is...
