easiest way to do this is to move the default expression out and
abstract over what is substituted into it, using a dependent value for
the default and a descriptive value for defaultText
unfortunately we don't have a good way to represent defaults that
reference other values of the current submodule, so we just use the
relative path of the referenced value and assume that the submodule was
declared as `rec`.
instead of keeping a defaultConfig value around, set that value as the
default of the option and explicitly use the option default instead.
this also allows us to write a defaultText that makes sense and is in
proximity to the definition of the default.
some options have default that are best described in prose, such as
defaults that depend on the system stateVersion, defaults that are
derivations specific to the surrounding context, or those where the
expression is much longer and harder to understand than a simple text
snippet.
escape interpolations in descriptions where possible, replace them with
sufficiently descriptive text elsewhere. also expand cfg.* paths in
descriptions.
adds defaultText for all options that use `cfg.*` values in their
defaults, but only for interpolations with no extra processing (other
than toString where necessary)
the kubernetes modules cross-reference their config using an additional shortcut
binding `top = config.services.kubernetes`, expand those to defaultText like
`cfg` previously.
This reverts commit 6af3d13bec.
Reported by @arcnmx
(https://github.com/NixOS/nixpkgs/pull/148179#issuecomment-987197656):
Does this not completely break the service? It doesn't change the
owner to the same as the ddclient server (which is somewhat difficult
due to it being a DynamicUser), so this now makes the service
completely unusable because the config is only readable by its owner,
root:
ddclient[871397]: WARNING: file /run/ddclient/ddclient.conf: Cannot open file '/run/ddclient/ddclient.conf'. (Permission denied)
Given that the RuntimeDirectory was only readable by the ddclient
service, the warning this PR fixes was spurious and not indicative of
an actual information leak. I'm not sure of what a quick fix would be
due to DynamicUser, but would at least request a revert of this so the
service can work again?
This is horrible if you want to debug failures that happened during
system switches but your 30-ish acme clients spam the log with the same
messages over and over again.
