Add name option when running experiments

[BradyJ27]

When modifying parameters and running (or queueing) an experiment, there should exist an option somewhere to set the name of the experiment. This can especially help when running multiple experiments at a time.

My idea of how this would be implemented is the first popup when a user clicks "Modify Workspace Params and ...," would be a "Experiment Name" popup. It also could be left blank for a random name. The corresponding CLI way of doing this is dvc exp run -n less_epochs -S params.yaml:epochs=10

[mattseddon]

Thanks for the issue @BradyJ27.

My idea of how this would be implemented is the first popup when a user clicks "Modify Workspace Params and ...," would be a "Experiment Name" popup. It also could be left blank for a random name. The corresponding CLI way of doing this is dvc exp run -n less_epochs -S params.yaml:epochs=10

Some things to consider here.

• Extra step will get in the way for the bulk of users not wanting to add a name.
• Leaving blank for a random name could be difficult to implement because usually, no value means the user escaped and doesn't want to proceed.
• -n flag with when queuing leads to pretty unuseful names when using a range e.g.

dvc exp run -n less_epochs -S params.yaml:epochs='range(13,16,1)' --queue 
Queueing with overrides '{'params.yaml': ['epochs=13']}'.                                                                                                                                         
Queued experiment 'less_epochs-1' for future execution.
Queueing with overrides '{'params.yaml': ['epochs=14']}'.                                                                                                                                         
Queued experiment 'less_epochs-2' for future execution.
Queueing with overrides '{'params.yaml': ['epochs=15']}'.                                                                                                                                         
Queued experiment 'less_epochs-3' for future execution.

[BradyJ27]

@mattseddon I definitely see your points. How feasible is something like changing the name after the experiment is run? I.e. I run x experiments, then double click on the name of one and change it, so I can keep track of which is which.

• Extra step will get in the way for the bulk of users not wanting to add a name.

This prevents the extra step and makes it optional for all users.

• -n flag with when queuing leads to pretty unuseful names when using a range

This also could allow for better naming of ranges, i.e. 9-epochs, 10-epochs, and so on.

Not sure if this is feasible to implement, but when running multiple experiments on a workspace, it can be cumbersome to keep track of which is which, especially when dealing with a lot of params (like yolo).

[mattseddon]

The second suggestion seems more like labels from back in #1720:

If we were to implement these I think we would drop stars.

As a workaround/in the meantime take a look at this functionality:

Screen.Recording.2023-07-24.at.11.23.06.am.mov

Stars along with the "starred" filter can be used to temporarily cut down the number of records in the table. Columns that you are interested in can be moved to the start of the table via the context menu.

We'll talk about options/priorities in our weekly planning meeting in a couple of days 👍🏻.

[dberenbaum]

Could also be related to iterative/dvc#6667

[mattseddon]

We'll talk about options/priorities in our weekly planning meeting in a couple of days 👍🏻.

We touched on this briefly in the planning meeting. @shcheklein will have a conversation/gather more feedback next week.

[BradyJ27]

I've created a PR here for related issue iterative/dvc#6667

[SoyGema]

Hey hi,

Just to share a thought that might complement the closed issue as a conclusion , WRT to the renaming-table W&B comparison scenario AFTER the experiment was created, the User Experience of renaming after the run and possibly adding notes ended up in an scenario in which I had more ownership and more flexibility of the table when I was working with it .
Renaming + labeling -as Notes substitute - might work as well ?

[BradyJ27]

Hey hi,

Just to share a thought that might complement the closed issue as a conclusion , WRT to the renaming-table W&B comparison scenario AFTER the experiment was created, the User Experience of renaming after the run and possibly adding notes ended up in an scenario in which I had more ownership and more flexibility of the table when I was working with it .
Renaming + labeling -as Notes substitute - might work as well ?

Hi,

I've already created a PR for renaming experiments after the fact. Adding labels or tags or something similar could be a useful feature. Maybe @mattseddon has more to offer on that side of things.

I know there is a comment above that shows an old concept of labels, not sure if that would help your use case.

[SoyGema]

Hey I didn't know that the flag you propose enabled editing directly from the table in the extension ( is that the case? ) ...

Thought it was purely CLI option based! ( that's why I opened another issue in the first place, a little bit confusing IMO ) For me the value prop is NOT to do it from console... :) ...

Glad to see some contribs coming 👾

[BradyJ27]

@SoyGema the flag is for the CLI, but the idea of this ticket is to add that functionality to the extension once that cli flag is complete.