-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add log_param/log_params #292
Conversation
3c47348
to
cb94d93
Compare
Codecov ReportBase: 94.81% // Head: 51.83% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #292 +/- ##
===========================================
- Coverage 94.81% 51.83% -42.98%
===========================================
Files 34 34
Lines 1523 1634 +111
Branches 166 183 +17
===========================================
- Hits 1444 847 -597
- Misses 58 782 +724
+ Partials 21 5 -16
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Should we log into Otherwise, what is the plan to support this in both - Studio/VS Code? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
A couple of comments. I have tried to differentiate implementation vs product comments.
Not sure if product discussions should happen here or in Notion cc @dberenbaum (I am Ok with discussing here)
src/dvclive/live.py
Outdated
output_dir = Path(self.dir) / self.PARAMS_DIR | ||
output_dir.mkdir(exist_ok=True) | ||
params_path = output_dir / ( | ||
f"{name}.json" if not name.endswith(".json") else name | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Implementation)
Not a blocker but, for consistency, I think would be nice if we implement a new Data
subclass (i.e. Param
) and move this logic there.
It would look more similar to the other log_x
methods and could launch explicit exceptions for invalid data types, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, and that's the first approach I went for, although if you look at the Data
class most of its (abstract) methods are tightly connected to the "stepped" workflow: step
, no_step_output_path
, first_step_dump
, no_step_dump
, step_dump
. Maybe have a new superclass from which Data
and Param
derive, although I think they would share only few methods/attributes.
I think a Param
class is something we will have to add, especially in relation to the nested dictionaries/complex objects parameters support.
I'm not sure if it simplifies migration to put them into
This is still under discussion, but a custom params file could be supported through |
+1
One reason I see for preferring YAML is to provide users with an example on how a "standard" |
43831b0
to
0453396
Compare
Note: linting failures on mac/win 3.10 seem unrelated |
@dtrifiro Do you want to migrate to a YAML file? I actually don't think |
@dberenbaum That sounds good. Although in order to remain consistent with dvc, I think we'd have to use the facilities included in |
2196bad
to
cad9909
Compare
Discussed with @dtrifiro and decided that we should be able to implement basic YAML parsing without copying all of the DVC YAML serialization utilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor comments and good to go.
Main doubt:
(Product) I am missing the point of YAML
vs JSON
but I have no strong opinion. I just think the right direction would be to implement iterative/dvc#7939 and save us the new dependency / extra utils code.
Must address:
(Implementation) @dtrifiro Need to either make all imports of ruamel.yaml
optional (with try/except ImporError
or lazy import) or add as a install_requires
dependency.
@daavoo Not sure I understand your point (I also have no strong opinion on |
If I understood the motivation for |
c90f723
to
15805f0
Compare
Addressed the remaining comments.
Do we really need this? We can already specify custom params files, although we "nudge" users towards using |
Good point. I would say YAML is arguably more easily readable and editable and maybe more common for parameters, but JSON is not so different, has fewer issues, and is already used for metrics, so 🤷 . Let's merge this and we can come back to it if needed in the future. Edit: @daavoo Not sure if you were thinking that a default params file would save DVC from needing to specify parameters outside of a pipeline. Even if params are written to the default file, |
15805f0
to
27a6c0c
Compare
Provides two new methods which log parameters to a yaml file (
params.yaml
):log_param(name, value)
logs the given parameter name/valuelog_params(params)
logs the given set of parameters (dict).