yocto-gl
yocto-gl copied to clipboard
Refactor mlflow pipelines code in preparation for classification template
Signed-off-by: Brian Barnes [email protected]
What changes are proposed in this pull request?
This PR makes a few small adjustments to step implementations and utility methods that are tightly coupled to the only existing template (regression). It does so as succinctly as possible in an effort to avoid a larger refactor, and compromises a bit on code quality as a result. In particular, the introduction of utility functions that switch on the template type is an anti-pattern, a cleaner approach would be to introduce an interface with methods such as get_builtin_metrics
and implement a new object for each template type that implements this interface.
How is this patch tested?
The MLP regression template was run locally with these changes.
Does this PR change the documentation?
- [x] No. You can skip the rest of this section.
- [ ] Yes. Make sure the changed pages / sections render correctly by following the steps below.
- Click the
Details
link on thePreview docs
check. - Find the changed pages / sections and make sure they render correctly.
Release Notes
Is this a user-facing change?
- [x] No. You can skip the rest of this section.
- [ ] Yes. Give a description of this change to be included in the release notes for MLflow users.
(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
What component(s), interfaces, languages, and integrations does this PR affect?
Components
- [ ]
area/artifacts
: Artifact stores and artifact logging - [ ]
area/build
: Build and test infrastructure for MLflow - [ ]
area/docs
: MLflow documentation pages - [ ]
area/examples
: Example code - [ ]
area/model-registry
: Model Registry service, APIs, and the fluent client calls for Model Registry - [ ]
area/models
: MLmodel format, model serialization/deserialization, flavors - [x]
area/pipelines
: Pipelines, Pipeline APIs, Pipeline configs, Pipeline Templates - [ ]
area/projects
: MLproject format, project running backends - [ ]
area/scoring
: MLflow Model server, model deployment tools, Spark UDFs - [ ]
area/server-infra
: MLflow Tracking server backend - [ ]
area/tracking
: Tracking Service, tracking client APIs, autologging
Interface
- [ ]
area/uiux
: Front-end, user experience, plotting, JavaScript, JavaScript dev server - [ ]
area/docker
: Docker use across MLflow's components, such as MLflow Projects and MLflow Models - [ ]
area/sqlalchemy
: Use of SQLAlchemy in the Tracking Service or Model Registry - [ ]
area/windows
: Windows support
Language
- [ ]
language/r
: R APIs and clients - [ ]
language/java
: Java APIs and clients - [ ]
language/new
: Proposals for new client languages
Integrations
- [ ]
integrations/azure
: Azure and Azure ML integrations - [ ]
integrations/sagemaker
: SageMaker integrations - [ ]
integrations/databricks
: Databricks integrations
How should the PR be classified in the release notes? Choose one:
- [ ]
rn/breaking-change
- The PR will be mentioned in the "Breaking Changes" section - [x]
rn/none
- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" section - [ ]
rn/feature
- A new user-facing feature worth mentioning in the release notes - [ ]
rn/bug-fix
- A user-facing bug fix worth mentioning in the release notes - [ ]
rn/documentation
- A user-facing documentation change worth mentioning in the release notes