David de la Iglesia Castro

> I created an issue in the `mmcv` repository and I am not entirely sure, but it seems the `by_epoch` argument does do what I would expect it to do...

I see your points and totally agree with encouraging the separation between `params` and code. However I see a few "counterpoints": > > When using `dvclive` as an alternative to...

For reference, review existing *ML Logger* integrations with `Optuna` #118, which is an *Hyperparameter Optimization Framework*. It looks like `log_param` could be more useful when integrating with *Hyperparameter Optimization Frameworks*...

> I'd be interested to hear what @daavoo thinks. In the past, I have logged whatever I can about the model object, which mostly included implicit parameters like default values...

@pared @dberenbaum

> > A) If `checkpoint: true` is set in DVC and `model_file` is None in DVCLive: we use the value of the output as `model_file` . > > What do...

> @daavoo That would work only in integrations, right? With the current implementation, yes.

> but dvclive should probably handle this kind of error more gracefully. Maybe it can skip that plot but still generate the rest of the report? I cut corners based...

We would need to change the current API of `log_plot` a little bit. We currently use `name` (first arg) to select the plot template to use (https://dvc.org/doc/dvclive/api-reference/live/log_plot#supported-plots): ```python y_true =...

> is so sklearn-focused An additional argument towards a separate command is that, in the current sklearn plots, the inputs don't match what gets saved in the plot: (y_true, y_pred)...