You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Re the discussion here, it's common to want multiple envs/flags to configure the same underlying option value esp. when refactoring the command line interface.
@mafredri proposes the concept of an OptionAlias that embeds within each Option like so:
typeOptionAliasstruct {
Flagstring`json:"flag,omitempty"`FlagShorthandstring`json:"flag_shorthand,omitempty"`Envstring`json:"env,omitempty"`Deprecatedstring`json:"deprecated,omitempty"`
}
// Option is a configuration option for a CLI application.typeOptionstruct {
Aliases []OptionAlias`json:"aliases,omitempty"`// ...
}
// Usage:
{
// ...Env: "CODER_FOOBAR",
Alias: []serpent.OptionAlias{
{Env: "FOOBAR", Deprecated: "Use CODER_FOOBAR instead."},
},
},
I think the extra level of nesting on all options is unjustified when in the vast majority of options there is only one "alias".
The text was updated successfully, but these errors were encountered:
Re the discussion here, it's common to want multiple envs/flags to configure the same underlying option value esp. when refactoring the command line interface.
@mafredri proposes the concept of an
OptionAlias
that embeds within each Option like so:I think the extra level of nesting on all options is unjustified when in the vast majority of options there is only one "alias".
The text was updated successfully, but these errors were encountered: