[Nix-dev] More Typing and nested mkOptions

[Nicolas Pierron]

Hi Artyom,

On Thu, Jan 8, 2009 at 13:01, Artyom Shalkhakov
<artyom.shalkhakov at gmail.com> wrote:
> Can anybody tell me if it's possible to nest mkOptions?
> (I've tried to look up it's implementation, but noticed
> strange __names and didn't look further).

Currently it is not possible to safely add nested options, but this is possible.

> Here's an example (oversimplified):
>
> /* Each potential network/access point should have a
>   "network block" that describes how to identify it and
>   how to set up security. (from the wpa_supplicant man)
> */
> interfaces = mkOption {
>   default = [] # nothing by default
>   # how do you describe the following?
>   example = {
>     name = "foobar"; # name of the interface
>     networks = [
>       ...
>     ];
>   }
> }

I think there is a problem in your example because your example does
not have the same ""type"" (list vs attrset).  So I guess you mean
something like:

interfaces = mkOption {
  default = [] # no default interface
  example = [ {
    name = "foobar"; # name of the interface
    ... # interface properties
  } ];
}

I suggest you to have a look at upstart-jobs/filesystem.nix which
seems a bit similar.

> Also, how about some typing or meta-information? For
> example, if we gave each option a type (a set of possible
> values, that is), we could check user input, generate more
> documentation, build simple administrative GUIs, and so on.

If you want to check the option value defined by the user, you can use
the "merge" function of the option to check this property.  This
feature is already used to ensure a specific input (type) and can be
used to limit the input to a specific set of values.

By the way I don't think that a set of possible values could be enough
for everyone.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.