-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Supporting kwargs in log figure #9179
Conversation
Signed-off-by: lc3267 <[email protected]>
Signed-off-by: lc3267 <[email protected]>
Signed-off-by: lc3267 <[email protected]>
Documentation preview for d8b9e02 will be available here when this CircleCI job completes successfully. More info
|
mlflow/tracking/client.py
Outdated
@@ -1234,6 +1234,7 @@ def log_figure( | |||
run_id: str, | |||
figure: Union["matplotlib.figure.Figure", "plotly.graph_objects.Figure"], | |||
artifact_file: str, | |||
**kwargs, |
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.
**kwargs, | |
*, | |
kwargs, |
Can we make this a separate argument? In the future, we might add a new argument to this function and it may conflict with plotly or matplotlib. I think this is a little inconvenient but better than argument name collisions.
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 see, good point! Should we then also rename kwargs
to sth. more expressive, e.g. figure_args
or plotting_args
(open to other suggestions), so that it is clear that those arguments are being passed to the plotting backend?
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.
xxx_args
sounds like it takes a tuple. I'd prefer xxx_kwargs
.
figure_kwargs
plot_kwargs
plotting_kwargs
extra_kwargs
save_kwargs
extras
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.
save_kwargs
(meaning keyword arguments used when saving)?
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.
kwargs
doesn't sound bad because we probably won't add an argument named kwargs
to log_figure
.
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.
save_kwargs
sound good, the other suggestions like figure_kwargs
might cause confusion as it could be interpreted as altering the figure itself. Also sticking with kwargs
is fine by me 😃
Is there maybe another (similar) case in the mlflow api where we could reuse the naming convention for additional kwargs passed to the backend?
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 like save_kwargs
:) It's more descriptive than kwargs
. We have saved_model_kwargs
here in the mlflow.tensorflow
module:
mlflow/mlflow/tensorflow/__init__.py
Line 199 in 0e856e2
:param saved_model_kwargs: a dict of kwargs to pass to ``tensorflow.saved_model.save`` method. |
save_kwargs
aligns with this pattern.
mlflow/tracking/client.py
Outdated
figure.write_html(tmp_path, include_plotlyjs="cdn", auto_open=False) | ||
kwargs.setdefault("include_plotlyjs", "cdn") | ||
kwargs.setdefault("auto_open", False) | ||
|
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.
@stroblme Sorry for the late review, left a few comments! |
Signed-off-by: harupy <[email protected]>
@stroblme I pushed a commit to use |
Signed-off-by: harupy <[email protected]>
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.
Thanks, looks good!
Good idea to add a test as well, wasn't sure how to check if it actually renders the Latex, but at least the interface is tested now.
Signed-off-by: harupy <[email protected]>
Signed-off-by: harupy <[email protected]>
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.
LGTM!
@stroblme Thanks for the contribution! |
Related Issues/PRs
Resolve #9149
What changes are proposed in this pull request?
**kwargs
tolog_figure(..)
and passed them to corresponding export methods for both matplotlib and plotlysetdefault
to merge previously existing arguments inkwargs
How is this patch tested?
Existing unit/integration tests
New unit/integration tests
Manual tests (describe details, including test results, below)
ran only tracking related unit tests (
pytest tests/tracking/test_log_figure.py
)manual test code based on example provided in method documentation:
include_mathjax="cdn"
) :Does this PR change the documentation?
Release Notes
Is this a user-facing change?
(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
Additional arguments can be passed to both Matplotlib and Plotly export methods. This enables specifying e.g. MathJax CDN
required for Plotly figures with formulas as mentioned in #9149
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/artifacts
: Artifact stores and artifact loggingarea/build
: Build and test infrastructure for MLflowarea/docs
: MLflow documentation pagesarea/examples
: Example codearea/gateway
: AI Gateway service, Gateway client APIs, third-party Gateway integrationsarea/model-registry
: Model Registry service, APIs, and the fluent client calls for Model Registryarea/models
: MLmodel format, model serialization/deserialization, flavorsarea/recipes
: Recipes, Recipe APIs, Recipe configs, Recipe Templatesarea/projects
: MLproject format, project running backendsarea/scoring
: MLflow Model server, model deployment tools, Spark UDFsarea/server-infra
: MLflow Tracking server backendarea/tracking
: Tracking Service, tracking client APIs, autologgingInterface
area/uiux
: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/docker
: Docker use across MLflow's components, such as MLflow Projects and MLflow Modelsarea/sqlalchemy
: Use of SQLAlchemy in the Tracking Service or Model Registryarea/windows
: Windows supportLanguage
language/r
: R APIs and clientslanguage/java
: Java APIs and clientslanguage/new
: Proposals for new client languagesIntegrations
integrations/azure
: Azure and Azure ML integrationsintegrations/sagemaker
: SageMaker integrationsintegrations/databricks
: Databricks integrationsHow should the PR be classified in the release notes? Choose one:
rn/breaking-change
- The PR will be mentioned in the "Breaking Changes" sectionrn/none
- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/feature
- A new user-facing feature worth mentioning in the release notesrn/bug-fix
- A user-facing bug fix worth mentioning in the release notesrn/documentation
- A user-facing documentation change worth mentioning in the release notes