There are a number of different syntaxes used for attrset type
signatures in our doc strings, this change standardises upon one that
uses :: for specifying attribute type, and ; terminators to be
consistent with nix syntax. There are no bugs in the functions
themselves, just that different syntaxes may confuse new users.
Render un`_type`d defaults and examples as `literalExpression`s using
`lib.generators.toPretty` so that consumers don't have to reinvent Nix
pretty-printing. `renderOptionValue` is kept internal for now intentionally.
Make `toPretty` print floats as valid Nix values (without a tilde).
Get rid of the now-obsolete `substSpecial` function.
Move towards disallowing evaluation of packages in the manual by
raising a warning on `pkgs.foo.{outPath,drvPath}`; later, this should
throw an error. Instead, module authors should use `literalExpression`
and `mkPackageOption`.
Personally, I think that warnings such as
warning: The option `services.redis.enable' defined in `/home/ma27/Projects/nixpkgs/test.nix@node-vm' has been renamed to `services.redis.servers..enable'.
are fairly confusing because of the `..` and it's more correct to
actually quote that. With this change the warning now looks like this:
warning: The option `services.redis.enable' defined in `/home/ma27/Projects/nixpkgs/test.nix@node-vm' has been renamed to `services.redis.servers."".enable'.
While implementing that I realized that you'd have
a similar problem whenever you use attribute-names that aren't
identifiers, e.g.
services.nginx.virtualHosts."example.org".locations."/".invalid = 23;
now results in the following error:
error: The option `interactive.nodes.vm.services.nginx.virtualHosts."example.org".locations."/".invalid' does not exist. Definition values:
- In `/home/ma27/Projects/nixpkgs/test.nix@node-vm': 23
Of course there are some corner-cases where this won't work: when
generating the manual, you display submodules like this:
services.nginx.virtualHosts.<name>
Since `<name>` isn't a value, but an indicator for a submodule, it must
not be quoted. This also applies to the following identifiers:
* `*` for `listOf submodule`
* `<function body>` for `functionTo`
This might not be correct if you actually have a submodule with an
attribute name called `<name>`, but I think it's an improvement over the
current situation and for this you'd probably need to make even more
complex changes to the module system.
deprecate literalDocBook by adding a warning (that will not fire yet) to
its uses and other docbook literal strings by adding optional warning
message to mergeJSON.
types.optionSet has been deprecated for almost 10 years now
(0e333688ce)! A removal
was already attempted in 2019
(27982b408e), but it was promptly
reinstantiated since some third-party uses were discovered
(f531ce75e4).
It's finally time to remove it for good :)
Makes all options rendered in the manual throw an error if they don't
have a type specified.
This is a follow-up to #76184
Co-Authored-By: Silvan Mosberger <contact@infinisil.com>
This is a squashed commit. These are the original commit messages:
lib/option: Improve comment
better comment
Update documentation
Updated nixos/doc/manual/development/options-declarations.md with info on mkEnableOption and mkPackageOption.
Updated the comment on mkEnableOption in lib/options.nix
remove trailing whitespace
nixos/doc/option-declarations: Update IDs & formatting
nixos/docs/option-declarations: Escape angle brackets
Build DB from MD
(Amended) Fix typo
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
(Amended) Build DB from MD (again)
This is a squashed commit. These are the original commit messages:
lib/options: Add mkPackageOption
lib/options: Add missing semicolon
lib/options.nix: Make mkPackageOption more complicated
lib/options: Fix indent. & spacing
lib/options.nix: Remove example and align comment
lib/options: ravenous overuse of arguments
lib/options: Format better
lib/options: Add default examplePath decl
lib/options: Make better mkPackageOption function
lib/options: Remove trailing whitespace
lib/options: Improve mkPackageOptions
lib/options: Remove pkgs prefixing
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
lib/options: Slim down mkPackageOption further
lib/options: mkPackageOption: Add "pkgs." to example
lib/options: mkPackageOption: Make name & pkgs single arguments
lib/options: mkPackageOption: Swap name & pkgs
lib/options: Remove unnecessary import
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
As suggested in #131205.
Now it's possible to pretty-print a value with `lib.generators` like
this:
with lib.generators;
toPretty { }
(withRecursion { depthLimit = 10; } /* arbitrarily complex value */)
Also, this can be used for any other pretty-printer now if needed.
When having a bogus declaration such as
{ lib, ... }:
{
foo.bar = mkOption {
type = types.str;
};
}
the evaluation will terminate with a not-so helpful
error: stack overflow (possible infinite recursion)
To make sure a useful error is still provided, I added a `depthLimit` of
`10` which should be perfectly sufficient to `toPretty` when it's used
in an error-case for `showDefs`.
For an option definition that uses `lib.options.mergeEqualOption`
underneath, like `types.anything`, an error is thrown when multiple
functions are assigned, indicating that functions can't be compared for
equivalence:
error: The option `test' has conflicting definition values:
- In `xxx': <function>
- In `xxx': <function>
(use '--show-trace' to show detailed location information)
However, the error message didn't use the correct files. While above
error indicates that both definitions are in the xxx file, that's in
fact not true. Above error was generated with
options.test = lib.mkOption {
type = lib.types.anything;
};
imports = [
{
_file = "yyy";
test = y: y;
}
{
_file = "xxx";
test = x: x;
}
];
With this change, the error uses the correct file locations:
error: The option `test' has conflicting definition values:
- In `xxx': <function>
- In `yyy': <function>
(use '--show-trace' to show detailed location information)
Initially https://github.com/NixOS/nixpkgs/pull/82897 prevented
non-visible options from being rendered in the manual, but
visible-but-internal options were still being recursed into. This fixes
this, aligning the recurse condition here with the one in
make-options-doc/default.nix
Nix can perform static scope checking, but whenever code is inside
a `with` expression, the analysis breaks down, because it can't
know statically what's in the attribute set whose attributes were
brought into scope. In those cases, Nix has to assume that
everything works out.
Except it doesnt. Removing `with` from lib/ revealed an undefined
variable in an error message.
If that doesn't convince you that we're better off without `with`,
I can tell you that this PR results in a 3% evaluation performance
improvement because Nix can look up local variables by index.
This adds up with applications like the module system.
Furthermore, removing `with` makes the binding site of each
variable obvious, which helps with comprehension.
This is used in in the manual generation for option identifiers that can
be linked. This, unike what the example describes, doesn't preserve
quotes which is needed for these identifiers to be valid.
This reverts commit 124cccbe3b.
124cccbe3b
broke the build of NixOS manual.
It does not make sense to be as strict as with attributes since we
are not limited by the CLI's inability to handle numbers.
Placeholders should not be quoted either as they are not part of Nix
syntax but a meta-level construct.
