What advantages do you see to pass func args via kwargs to the function compare to existing execution ?
I guess, user makes it more explicit what parameters are passed to the Training Function compare to passing parameters dict, right ?

What do you think about this approach @droctothorpe @kubeflow/wg-training-leads @Electronic-Waste ?
Another idea could be to ask users to pass parameters to the function via ENVs.

I think the existing approach has already met with the need of users. Maybe we could adopt this apporach when users claim they need it:)

What advantages do you see to pass func args via kwargs to the function compare to existing execution ?
I guess, user makes it more explicit what parameters are passed to the Training Function compare to passing parameters dict, right ?

Right, from the end-user standpoint, that changes the signature contract of the training function, so instead of writing something like:

def train_func(dict):
    batch_size = dict.get("batch_size", 64)
    test_batch_size = dict.get("test_batch_size", 1000)
    epochs = dict.get("epochs", 10)
    lr = dict.get("lr", 0.01)
    gamma = dict.get("gamma", 0.7)
    dry_run = dict.get("dry_run", False)
    seed = dict.get("seed", 1)
    save_model = dict.get("save_model", False)

    # ...

Users can write:

def train_func(batch_size=64,
               test_batch_size=1000,
               epochs=10,
               lr=0.01,
               gamma=0.7,
               dry_run=False,
               seed=1,
               log_interval=10,
               save_model=False):

    # ...

As a user myself in that case, I find it clearer, and fail to see any drawbacks.

That make sense. @kubeflow/wg-training-leads @droctothorpe @deepanker13 What do you think about this approach ?
Did we try to explore how other frameworks/projects solve it ? For example, I was looking at Ray Train, and they follow similar approach with the train_loop_config parameter.