markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
This is a more sane default since we do not magically (without opt-in)
pull in binaries from `~/bin`. That is not really an expected behavior
for many users. Users that still want that behavior can now just flip
that switch.
A shared exported guard `__NIXOS_SET_ENVIRONMENT_DONE` is introduced that can
be used to prevent child shells from sourcing `system.build.setEnvironment`
the second time.
This fixes e.g. `nix run derivation` when run from e.g. ZSH through the console or
ssh. Before this Bash would resource the common environment resetting the `PATH`
environment variable.
We also export `system.build.setEnvironment` to `/etc/set-environment` making it
easy to reset the common environment with `. /etc/set-environment` when
needed and to grep for environment variables in `/etc` (which was the
motivation of #30418).
This reverts changes made in b00a3fc6fd
(the original #30418).
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
Should bring most of the examples into a better consistency regarding
syntactic representation in the manual.
Thanks to @devhell for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
E.g.
The unique option `fileSystems./.device' is defined multiple times, in `/etc/nixos/configuration.nix' and `/etc/nixos/foo.nix'.
This requires passing file/value tuples to the merge functions.
For instance, if time.timeZone is defined multiple times, you now get
the error message:
error: user-thrown exception: The unique option `time.timeZone' is defined multiple times, in `/etc/nixos/configurations/misc/eelco/x11vnc.nix' and `/etc/nixos/configuration.nix'.
while previously you got:
error: user-thrown exception: Multiple definitions of string. Only one is allowed for this option.
and only an inspection of the stack trace gave a clue as to what
option caused the problem.
The major changes are:
* The evaluation is now driven by the declared options. In
particular, this fixes the long-standing problem with lack of
laziness of disabled option definitions. Thus, a configuration like
config = mkIf false {
environment.systemPackages = throw "bla";
};
will now evaluate without throwing an error. This also improves
performance since we're not evaluating unused option definitions.
* The implementation of properties is greatly simplified.
* There is a new type constructor "submodule" that replaces
"optionSet". Unlike "optionSet", "submodule" gets its option
declarations as an argument, making it more like "listOf" and other
type constructors. A typical use is:
foo = mkOption {
type = type.attrsOf (type.submodule (
{ config, ... }:
{ bar = mkOption { ... };
xyzzy = mkOption { ... };
}));
};
Existing uses of "optionSet" are automatically mapped to
"submodule".
* Modules are now checked for unsupported attributes: you get an error
if a module contains an attribute other than "config", "options" or
"imports".
* The new implementation is faster and uses much less memory.
