Ability to change override order

[rusmux]

🚀 Feature request

Add the ability to change the override order. In the documentation it's said that CLI arguments (including config files) take precedence over env variables. It would be great to be able to configure this order.

Motivation

I think it's a valid approach to set one config file and update it with env variables. This can be very useful in containerised deployments, when services can be dynamically configured with env variables. For example, this is my entry point in the Docker image:

python -m main --config config.yaml

And I would like to update its config before start by setting the environment variable:

APP__SOME_VALUE: new

[mauvilsa]

At least for the example above, you can already get the behavior you want.

• Copy the config to a specific location, e.g. /app/config.yaml
• Configure the parser with default_config_files=["/app/config.yaml"]
• Run main without command line arguments python -m main
• With this all environment variables would override what is in the config.

[rusmux]

Thank you, that works, but I guess, it's still would be nice to have this feature, because users may want to change their config file location without updating the code. Or if they cannot set default_config_files because it's not their code, but a library providing the CLI

[mauvilsa]

I guess the proposal here is only to be able to move 5. Command line arguments in order left to right before the env vars parsing. Not changing the override order to any permutation.

In a fixed environment like a container, using a fixed config location with default_config_files would be the recommended approach. If default_config_files not yet set in the code, then changing the code would be preferable before using it in a container. On the other hand, in interactive environments the command line is what gets written last and executed by the user. Giving precedence to environment variables doesn't seem logical to me.

The strongest argument for this feature would be a CLI in a library not controlled by someone. But still I am not convinced. Requesting a change in the library would be the optimal solution. And also I think there would be workarounds that wouldn't require modifying the library, which would be preferable than adding complexity to jsonargparse.

For now I wouldn't plan to add this feature. But rather keep this issue open for other people to show interest.