Alright cool!
I will check it out and let you know what it was.

Is there some verbose mode I could run it with?

I have the strong suspicion it is somewhat related to my parameters of the function or generally the hyperparameters gathered by the task automatically.

1.15.1

Yup.

I really don't know what it's about.

It doesn't affect the process. Everything seems to run fine.

If the warnings would provide a bit more info I could maybe pinpoint it better, but it's really all I got

Here are the codefiles for my pipelines.

They do not work yet, I am struggling with the pipeline stuff quite a bit.

But both pipelines always give these warnings.

None of these submodules are required for the tasks, they are there for a different part of the project dealing with data generation.

So even having them fetched (even when cached) is quite the delay on the actual task.

None

Figured it out, I installed clearml[gs] but since I don't need that I removed it. it's gone now.

Hi @<1523701087100473344:profile|SuccessfulKoala55>

I am using 1.8.0 for the clearml-agent.

Attached is the logfile.

Hey. I should have closed this..

The thing that I was looking for is called set_parameter on the task.
The HPO uses a task I created previously and I had trouble with that, since it contained a path, which wasn't available on the colab instance.
I fixed my code, so it always updates this parameter depending on the environment.

It was less of an HPO issue, more of a programming failure on the function, which didn't properly update the parameter, even though I thought it should.

There has been a restart of my machine in the mean time :man-shrugging:
So only the matrix knows now I guess..

How can I adjust the parameter overrides from tasks spawned by the hyperparameter optimizer?

My template task has some environment depending parameters that I would like to clear for the newly spawned tasks, as the function that is run for each tasks handles the environment already.

If there's source URLs in the plots of the task, how can I authenticate against ClearML to properly download them?

Or is there some SDK way to download them?

I see

This here.. I know how to get the source code info, but it doesn't include the commit ID. And I also cannot access the uncommitted changes.

Thanks!

If it were possible to override the checkout behaviour I would ignore all submodules anyways, but in the documentation of clearml.conf as well as the pipeline decorator I couldn't find anything that would allow me doing that.

I cleared the vcs cache manually already, it results in the same behaviour illustrated above
(allthough the logs show that it used the cache, I had another run without cache - but don't have the logs from that)

Maybe it has something to do with my general environment? I am running on WSL2 in debian

No idea what's going on now, but I cannot reproduce the behaviour either.. also tried my old code posted here, but the warning doesn't pop up anymore.

I will inform once it pops again and will use the provided traceback function then.

I have a slight suspicion that it was indeed environment based on my local machine, but I have no idea what is the trigger for that.

It may or may not be related to this

2024-04-29 23:38:25,932 - clearml.Task - WARNING - Parameters must be of builtin ty...

Hem, yeah might be the case.

For anyone else interested in this, I wrote a little script which pulls all the data from a given project, seems to work well enough

I am getting the same when starting regular tasks.
I think it has something to do with my paramaters, which contain an environment variable which contains a list of datasets

What’s considered large in that case?

Yea, I get that.. But it's really hard to tell what's causing it due to the "<unknown>"

That is unfortunate.

I noticed poetry can be a problem in my run.
Not specifically due to the cache, but due to the installation of much more packages than the runtime might need.

When using regular pip, it will use the requirements list determined by ClearML to install necessary packages, which usually already excludes all dev-tools and similar.

I am not sure if poetry uses the cache properly, but I can't verify either atm.