This reverts commit 0f0805b, because @nbp had concerns about whether
this would be a good idea and pointed out problems with this.
We currently do not have a case where "either" is used in conjunction
with submodules, but I'm reverting it anyway to prevent people from
adding options using that type in that way.
This is now being reviewed in #14053.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far the "either" type only handled "flat" types, so you couldn't do
something like:
type = either int (submodule {
options = ...;
});
Not only caused this the submodule's options not being checked but also
not show up in the documentation.
This was something we stumbled on with #13916.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
- Enforce that an option declaration has a "defaultText" if and only if the
type of the option derives from "package", "packageSet" or "nixpkgsConfig"
and if a "default" attribute is defined.
- Enforce that the value of the "example" attribute is wrapped with "literalExample"
if the type of the option derives from "package", "packageSet" or "nixpkgsConfig".
- Warn if a "defaultText" is defined in an option declaration if the type of
the option does not derive from "package", "packageSet" or "nixpkgsConfig".
- Warn if no "type" is defined in an option declaration.
Nobody seems to have noticed this (except @Profpatsch) that options with
a "package" type do not get included in the manual.
So debugging this was a bit more involving because while generating the
manual there is an optionList' attribute built from the collected
attributes of all the option declarations.
Up to that point everything is fine except if it comes to
builtins.toXML, where attributes with { type = "derivation" } won't get
included, for example see here:
nix-repl> builtins.toXML { type = "derivation"; foo = "bar"; }
"<?xml version='1.0' encoding='utf-8'?>\n<expr>\n <derivation>
<repeated />\n </derivation>\n</expr>\n"
nix-repl> builtins.toXML { type = "somethingelse"; foo = "bar"; }
"<?xml version='1.0' encoding='utf-8'?>\n<expr>\n <attrs>
<attr name=\"foo\">\n <string value=\"bar\" />\n </attr>
<attr name=\"type\">\n <string value=\"somethingelse\" />
</attr>\n </attrs>\n</expr>\n"
The following function in libexpr/eval.cc (Nix) is responsible for toXML
dropping the attributes:
bool EvalState::isDerivation(Value & v)
{
if (v.type != tAttrs) return false;
Bindings::iterator i = v.attrs->find(sType);
if (i == v.attrs->end()) return false;
forceValue(*i->value);
if (i->value->type != tString) return false;
return strcmp(i->value->string.s, "derivation") == 0;
}
So I've renamed this now to "package" which is not only more consistent
with the option type but also shouldn't cause similar issues anymore.
Tested this on base of b60ceea, because building the dependencies on
recent libc/staging changes on master took too long.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Profpatsch <mail@profpatsch.de>
