Skip to content

Consolidate near-copy tune functions #222

@EmilHvitfeldt

Description

@EmilHvitfeldt

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(): the source == "cluster_spec" check is a real distinction. One option is to make tune's version accept a source argument; another is to keep the tidyclust copies but reduce them to only the differing line.
  • check_workflow() and check_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 the infra_pkgs difference is intentional.

Metadata

Metadata

Assignees

No one assigned

    Labels

    upkeepmaintenance, infrastructure, and similar

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions