weather-dl: Update CLI to accept multiple configs so we can queue downloads.

[Alex Merose]

Right now, weather-dl takes in one config file at a time and starts a download for them. Instead, the CLI could be updated to take multiple config files, such that once one config is finished, it will start the next one.

[Pangeran Bottor]

Hi @alxmrs, I plan to work on this and have a couple of questions:

1. should the CLI accept multiple configs as something like this:
   weather-dl config_1.cfg config_2.cfg --local-run
   or we just accept a folder path contains all the configs e.g.:
   weather-dl --config_folder /path/to/configs --local-run

2. I assume the option would be applied to all the configs, is that correct? So for the above example, we run every config on the local machine.

Thank you!

[Alex Merose]

Hey @pangeran-bottor, thanks for your contribution! A few thoughts:

1. The former. Users can use a glob star pattern to specify a folder of configs if they wish. On that note, we can encourage that usage by documenting examples of it.

2. Yes, all the flags applied should apply to all the configs.

Last, an open question: What parameters should take precedence? The first config's params, or does each config file get a say? Of particular concern here is how licenses are applied. For example, it would be convincing if I only needed to add licenses to the first config and they magically appeared in all of the rest. What are the downsides to doing this? Is this design question clear? Do you have an opinion on the matter?

[Pangeran Bottor]

Regarding the license, my first thought was each config file gets a say. For example, at first, we execute:
weather-dl config_1.cfg config_2.cfg --local-run,
but then somehow later we need to redownload only for config_2.cfg and since all flags applied to all the configs, we need to execute:
weather-dl config_2.cfg --local-run --force-download.
Would it be easier if config_2.cfg has its own params? Am I missing something on the tool's design?

1. The former. Users can use a glob star pattern to specify a folder of configs if they wish. On that note, we can encourage that usage by documenting examples of it.
2. Yes, all the flags applied should apply to all the configs.

Thanks and well noted on this.

[Alex Merose]

Ok, that makes sense to me. I like the example use case you bring up. Further, thinking about it more, the tool would be a bit more fragile if the order of arguments was important for the flow of execution. Better to strictly follow the interface we establish elsewhere.

You're not missing anything. One reason why I suggested the other approach is that it may make the implementation simpler.