Yes, that's what I'm doing right now. I was hoping there was something that felt a little less hacky.

Maybe. Will look into this. Thanks for the suggestion.

That seems to work. Thanks!

We usually use YAML objects rather than JSON objects, so our code littered with local saving of objects just so that we can upload them again as artifacts.

I would expect consistency in types I connected with those I retrieved.

Say I have a more complicated, nested dict of params, and I only want to send some of the nested keys to the GUI. I also want each one of those to be a "hyper parameters" field in the ClearML GUI. How do I connect each of these fields as such and return the correct types?

example:
config: field1: dict(param1=123, param2='text') field2: dict(param1=123, param2='text') field3: dict(param1=123, param2='text')
If I understand what you suggested above, doing ` task.connect(base...

How do I preserve types when using task.get_parameters_as_dict() or task.get_parameters() ?

If I connect the params via task.connect(input) , change via the GUI, and use one of the methods above, all int and float values turn into strings. This doesn't work very well for hyperparameters that are numerical.

Well, I connected a dictionary of params that needed to be accessible in the GUI via task.connect using a loop, where I was filtering that dictionary:

for k, v in config_dict.items(): if k not in ['element1', 'element2']: task.connect(v, name=k.lower())
It seemed more logical to return the params with a single call:

task_parameters = task.get_parameters_as_dict()

Follow up: I see that if I move an Experiment to a new project, it does not copy the associated model files and must be done manually. Once I moved the models to the new project, the query works as expected.

What is the advantage to returning only string types?

Ok. That's what I was thinking would be the next best alternative. Thanks.