Passing Trainer/Tuner method's (fit, predict) arguments through YAML or CLI

[ibro45]

If we allow only a certain root level config entries such as trainer, system, and whatever we end up calling CONSTANTS, we could also reserve the following: fit, predict, validate, test, tune, lr_find, and scale_batch_size (the last two are from Tuner). These would be passed directly to their respective argument when run.

Then either through CLI or YAML we could specify for example

lighter fit --config_file continue.yaml --fit#ckpt_path="./trained.ckpt"

fit#ckpt_path: trained.ckpt
# or
fit:
    ckpt_path: trained.ckpt

[surajpaib]

I think this is still not an ideal solution. Not that I can think of one.

I would prefer having something like method_args instead of each method actually reserved and defined. This way ckpt_path can be used for both fit, validate, test and predict if necessary.

If we want to keep each isolated then we should also somehow enforce arguments that can be provided there, which we wouldn't want to do.

[ibro45]

Any recent thoughts on this?

This prevents us from continuing training from a PL checkpoint or using the Tuner easily.

[ibro45]

This way ckpt_path can be used for both fit, validate, test and predict if necessary.

I would avoid this, gets confusing. I can easily think of it happening with continuing the training with fit and ckpt_path, and then wanting to predict, but forgetting to update method_args#ckpt_path. If the same value is needed, I'd rather explicitly refer to it from the other one, %fit#ckpt_path.

Also, a lot of these methods won't share the same arguments so there's more problems with it.