Some useful abstract module types.
impl is something that can fill a
command is an entry-point provided by an implementation.
Using a command may require extra dependencies (for example, a "test" command
might depend on a test runner).
An identifier for a command within a role.
A dependency indicates that an impl or command requires another role to be filled.
Get an implementation's dependencies.
The dependencies should be ordered with the most important first.
The solver will prefer to select the best possible version of an earlier
dependency, even if that means selecting a worse version of a later one
restricts_only dependencies are ignored for this).
An implementation or command can also bind to itself. e.g. "test" command that requires its own "run" command. We also return all such required commands.
This defines what the solver sees (hiding the raw XML, etc).
A restriction limits which implementations can fill a role.
Some selections previously produced by a solver. Note: logically, this should include CORE_MODEL, but that causes problems with duplicating RoleMap.
The result of running the solver.
Unlike the plain
SELECTIONS type, this type can relate the selections back
to the solver inputs, which is useful to provide diagnostics and the GUI.
The reason why the model rejected an implementation before it got to the solver.