Brainstorm: refactor to support registering custom ValueNode subclasses?

[Jasha10]

Idea:

I wonder if OmegaConf could be refactored so that adding support for a new, custom node type would be as simple as calling e.g. OmegaConf.register_custom_node_type(MyPathNode, pathlib.Path). This would be a step in the direction of enabling 3rd party packages to provide support for custom node types (pip install omegaconf-pathlib).

Background:

OmegaConf implements support for a core set of data types. For example:

• StringNode handles data typed as str
• IntegerNode handles data typed as int
• AnyNode handles untyped leaf-node data (and data typed as Any)
• etc.

We have several open feature requests and PRs looking to expand the set of supported node types. Here is a (possibly-incomplete) list:

• Support for bytes (Have bytes as supported value type. #844 and Include support for bytes built-in type. #872)
• Support for pathlib.Path (Add support for pathlib.Path type #97 and add pathlib.Path support #873)
• Support for datetime.datetime (Need datetime-typed field support #851)
• Support for typing.Literal (Allow the use of typing.Literal as a pythonic alternative to Enums #422 and Adds literal node #865)
• Support for typing.Union (Look into supporting Union in Structured configs #144)
• Support for tuple (Improve Tuple support #392)

While supporting common use-cases is a goal of OmegaConf, there are also risks involved with taking on many new node types:

• maintenance burden
• feature bloat

Some of the above node types are easier to implement than others. In the simplest case, support for a new leaf node type (such e.g. pathlib.Path) requires changing OmegaConf's source code in two places:

• define a new subclass of ValueNode must be defined (e.g. class PathNode(ValueNode): ...).
• Extend the switch statement in _node_wrap to handle the new type.

A simple case such as this could be handled by a OmegaConf.register_custom_node_type method, enabling extension as described in the introduction above.