Each instance of PipelineOptions contains a member called parser, which in turn is an instance of _BeamArgumentParser (which is a subclass of stdlib's ArgumentParser). Currently there is no way to affect the initialization of parser, as its class is hard-coded.
For example, I wanted to change the way that parser resolves conflicting CLI options. As per official docs, this is done by supplying the argument conflict_handler=... to the ArgumentParser constructor. Since there is no way for the user to affect the initialization of parser, this cannot currently be done. Changing conflict_handler after initialization, e.g. by doing options.parser.conflict_handler = ..., does not work since PipelineOptions objects may create other parser objects down the road, and CLI options are generally processed multiple times, so there is no guarantee that one is changing the conflict_handlerbefore any options are processed.
A simple solution would be to abstract out the class of parser:
What would you like to happen?
Each instance of
PipelineOptions
contains a member calledparser
, which in turn is an instance of_BeamArgumentParser
(which is a subclass of stdlib'sArgumentParser
). Currently there is no way to affect the initialization ofparser
, as its class is hard-coded.For example, I wanted to change the way that
parser
resolves conflicting CLI options. As per official docs, this is done by supplying the argumentconflict_handler=...
to theArgumentParser
constructor. Since there is no way for the user to affect the initialization ofparser
, this cannot currently be done. Changingconflict_handler
after initialization, e.g. by doingoptions.parser.conflict_handler = ...
, does not work sincePipelineOptions
objects may create other parser objects down the road, and CLI options are generally processed multiple times, so there is no guarantee that one is changing theconflict_handler
before any options are processed.A simple solution would be to abstract out the class of
parser
:In this way, the user may subclass
_BeamArgumentParser
in order to affect any initialization behavior:Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components