`--config <my-config-file>` largly ignored as defaults in argparse take precedence

If repo2docker --config <my-config-file> is used, boolean configuration will be ignored.

Example configuration in repo2docker_config.json

{
  "Repo2Docker": {
    "run": false,
    "push": true
  }
}

Example way to execute repo2docker where the configuration is ignored

repo2docker --config=repo2docker_config.json <some repo>

Background

repo2docker has traitlets based configuration and is derived from the traitlets library’s Application class. It can be provided both .py and .json file configuration. See Application.load_config.file() and note that it is used early.

https://github.com/jupyterhub/repo2docker/blob/b6098c02f315a37d690a0c538973de53dd0631a3/repo2docker/__main__.py#L282-L282

The issue is that a config file that provides a boolean value for Repo2Docker.run for example will be ignored when the repo2docker CLI is parsing its flags.

https://github.com/jupyterhub/repo2docker/blob/b6098c02f315a37d690a0c538973de53dd0631a3/repo2docker/__main__.py#L329-L330

This could be resolved if there was a way in argparse to check if a flag had been passed or not, or if a default value had been provided. I can imagine an ugly workaround like having a default value of “this-flag-was-not-set” and then check for that or similar, but I’d like to avoid that.

Is there a way to let the traitlets configured defaults be respected instead of beign overruled by the argparse provided defaults?

https://github.com/jupyterhub/repo2docker/blob/b6098c02f315a37d690a0c538973de53dd0631a3/repo2docker/app.py#L326-L332

Two sets of defaults?

When using the CLI, the defaultof run is True (becomes false if --no-run is passed), but when using Repo2Docker the application, it will be False by default. If we reconcile these to one default it would become a breaking change, either for the CLI or the library.

What to do?

I’m looking to make use of the repo2docker CLI, but relying on as much as possible to be provided via the provided configuration file. Like that, a repo2docker-service that is supposed to run repo2docker can accept a config file and execute repo2docker based on that config, but if values are ignored by default values, that is a problem.

[minrk]

traitlets’ own CLI parsing properly handles this, so maybe the argparse CLI should be replaced with the traitlets-standard Application.launch_instance(argv) ? Downside: more folks know how to argparse than mess with argparse via traitlets if we want to have finer control over the CLI.

An alternative is to have the default for all argparse values be None (or some Unspecified singleton, if None is a valid value that must be preserved), and only pass args to the App constructor that have been specified.

It will be a bit tricky for argparse to accurately present default values in this case, since the default in argparse is not actually he default value.

Perhaps a custom argparse Action can be used to do nothing other than notice which args have been passed explicitly?

[minrk]

#1211 implements much of this

• use default=None to make unspecified values distinguishable from cli default
• remove config=True from some options that I think don’t make sense in config files, either because the CLI always overrides them, or they don’t make sense to persist from one call to the next, or both