containertool: Don't set environment-variable defaults in parser

[euanh]

Motivation

Many containertool options have default values set by environment variables.

• if the option flag is set on the command line, the command line value is used
• otherwise, if the option flag is not set, the environment variable value is used
• otherwise, a hard-coded default is used

This pattern is quite convenient, but there are some drawbacks. For example:

• the default value declarations complicate the definition of new arguments.
• default values appear in the --help output: for some options, such as default base image, this is desirable, but for others, such as credentials, it is not.

Some options do not fit this pattern well. For instance, containertool tries to detect the architecture of the executable it is packaging so it can try to choose a compatible base image.

• if the architecture flag is set on the command line, that value is used
• otherwise, if the flag is not set, the environment variable value is used
• otherwise, if the executable is an ELF file, the architecture is read from the file
• otherwise, a hard-coded default is used

The path to the executable is an option which is parsed by the argument parser. It is not available when the parser sets up default argument values, so it must be handled after the arguments have been parsed, overwriting whatever the parser had set. This means that option handling for this flag is split into two different places, which invites bugs.

Future changes to containertool's configuration, such as supporting a configuration file on disk, add further complications.

Modifications

• All command line arguments with corresponding environment variables are handled uniformly, with defaults applied at the start of the run() function

Result

No functional change, but maintenance and future enhancement become easier.

Test Plan

All existing tests continue to pass.
Handling defaults in this way allows future PRs to add unit or integration tests which exercise argument parsing.