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
The three existing sources answer "what did this input say about field X". Flags
also have to answer the reverse — "what flags exist, and what does --help look
like" — which means registering a flag per field before parsing. The figureout.Source interface (Load(ctx, *Model) (*Layer, error)) covers the
first half only, so this needs either a pre-parse step or a wider interface.
Scope
flag.Name, flag.Short, flag.Skip, flag.Hidden, flag.Deprecated
field options, with names relative to the declaring object as env and
the tree sources already are (--server.listen-port, not --listen-port)
Derived names from the canonical path: server.listenPort → --server-listen-port
Help text from Doc, defaults from Default, allowed values from an
enum constraint, and the value placeholder from the semantic type
Booleans as presence-only flags (--debug, not --debug=true)
Lists as repeated flags, delimited values, or both
Unions: the discriminator is a flag, variant fields are flags alongside it
(the same inline layout the other sources use)
Origin reporting flag --server-listen-port so a bad value points at the
flag, not at a file
Open questions
Adapter target. The design lists flag.FlagSet, Cobra and Kong. Standard
library first, or an interface with adapters from the start?
Pre-parse registration. Add a Register(*Model) error step to the flag
source specifically, or widen figureout.Source with an optional interface
the resolver type-asserts?
Required fields. A required field with no default currently errors when
missing. With flags in the mix, does --help still work when required flags
are absent? It has to.
Merging. Repeated flags across one command line — MergeAppend within a
single layer, or does the flag source flatten before producing its layer?
Goal
A
source/flagadapter, so a descriptor also produces command-line flags:Why it is not just another source
The three existing sources answer "what did this input say about field X". Flags
also have to answer the reverse — "what flags exist, and what does
--helplooklike" — which means registering a flag per field before parsing. The
figureout.Sourceinterface (Load(ctx, *Model) (*Layer, error)) covers thefirst half only, so this needs either a pre-parse step or a wider interface.
Scope
flag.Name,flag.Short,flag.Skip,flag.Hidden,flag.Deprecatedfield options, with names relative to the declaring object as env and
the tree sources already are (
--server.listen-port, not--listen-port)server.listenPort→--server-listen-portDoc, defaults fromDefault, allowed values from anenum constraint, and the value placeholder from the semantic type
--debug, not--debug=true)(the same inline layout the other sources use)
flag --server-listen-portso a bad value points at theflag, not at a file
Open questions
flag.FlagSet, Cobra and Kong. Standardlibrary first, or an interface with adapters from the start?
Register(*Model) errorstep to the flagsource specifically, or widen
figureout.Sourcewith an optional interfacethe resolver type-asserts?
missing. With flags in the mix, does
--helpstill work when required flagsare absent? It has to.
MergeAppendwithin asingle layer, or does the flag source flatten before producing its layer?