StarlarkOptionsParser is part of overall options parsing but still separate: it uses an entirely different API from OptionsParser and many code paths that handle options only handle native options as a result.
An ideal end state API might look something like this:
A top-level OptionsParser that is responsible for splitting flags into keys and values
Handling both --flag value and --flag=value syntax
Handling the no boolean-negation prefix
Possibly handling string->value object conversion
A number of plugins for the parser to actually identify specific options (and parse values?)
A FieldOptionPlugin that handles "native" flags on OptionsBase subclasses, annotated with @Option
A StarlarkOptionPlugin that handles Starlark flags (including loading the actual target and rule to determine options data).
A unified system for then reporting flags values, handling diffs and merges, etc.
All of this is ambitious and won't happen soon, but I do plan to start some degree of convergence in order to durably expose Starlark option metadata via the existing OptionDefinition type.
StarlarkOptionsParser
is part of overall options parsing but still separate: it uses an entirely different API fromOptionsParser
and many code paths that handle options only handle native options as a result.Ideally, native flags (based on
OptionsBase
and@Option
) would use the same API as Starlark build settings.An ideal end state API might look something like this:
OptionsParser
that is responsible for splitting flags into keys and values--flag value
and--flag=value
syntaxno
boolean-negation prefixOptionsBase
subclasses, annotated with@Option
All of this is ambitious and won't happen soon, but I do plan to start some degree of convergence in order to durably expose Starlark option metadata via the existing
OptionDefinition
type.