-
Notifications
You must be signed in to change notification settings - Fork 20
Consolidate near-copy tune functions #222
Copy link
Copy link
Open
Labels
upkeepmaintenance, infrastructure, and similarmaintenance, infrastructure, and similar
Description
Several functions in tidyclust are near-copies of functions in tune, differing only in small cluster-specific ways. We should evaluate each one and either: import the tune version directly if the difference can be handled cleanly, or move the shared logic into tune and keep only the cluster-specific part in tidyclust.
All changes should be verified carefully — the differences are subtle and intentional in some cases.
Functions to evaluate
| Function(s) in tidyclust | Match in tune | Exported from tune? | Key difference |
|---|---|---|---|
merge.cluster_spec() / update_model() / update_recipe() |
merge.model_spec() etc. |
❌ No | Checks source == "cluster_spec" vs "model_spec" |
check_workflow() |
check_workflow() |
❌ No | Has cluster-specific guards (check_installs on cluster spec) |
check_metrics() |
check_metrics() |
❌ No | Checks for cluster_metric_set instead of generic metric sets |
load_pkgs.cluster_spec() |
load_pkgs.model_spec() |
✅ Yes (generic) | Dispatch on cluster_spec; infra_pkgs list differs slightly |
Notes
merge.cluster_spec()/update_model()/update_recipe(): thesource == "cluster_spec"check is a real distinction. One option is to make tune's version accept asourceargument; another is to keep the tidyclust copies but reduce them to only the differing line.check_workflow()andcheck_metrics()need to stay in some form but the bulk of their logic could live in tune with a hook for cluster-specific validation.load_pkgs.cluster_spec()is likely fine to keep as-is since it correctly dispatches on the cluster-specific class — verify theinfra_pkgsdifference is intentional.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
upkeepmaintenance, infrastructure, and similarmaintenance, infrastructure, and similar