From 48cff5fbc8acbf068431f8b84d62df48682ed1f8 Mon Sep 17 00:00:00 2001 From: Gleb Kanterov Date: Thu, 13 Mar 2025 13:15:56 +0100 Subject: [PATCH] [Python] Clarify rationale for mutator design --- .../databricks/bundles/core/_resource_mutator.py | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/experimental/python/databricks/bundles/core/_resource_mutator.py b/experimental/python/databricks/bundles/core/_resource_mutator.py index 2c35d9ca69..b871c0f3a5 100644 --- a/experimental/python/databricks/bundles/core/_resource_mutator.py +++ b/experimental/python/databricks/bundles/core/_resource_mutator.py @@ -52,6 +52,20 @@ def my_job_mutator(bundle: Bundle, job: Job) -> Job: """ +# Below, we define decorators for each resource type. This approach allows us +# to implement mutators that are only applied for specific resource types. +# +# Alternative approaches considered and rejected during design: +# +# - Inspecting type annotations without decorators. +# Rationale: Avoid implicit runtime behavior changes based solely on type annotations, +# especially if a function lacks an explicit decorator. +# +# - Using a universal @mutator decorator. +# Rationale: Determining whether a mutator is invoked based solely on type annotations +# was deemed overly implicit and potentially confusing. + + @overload def job_mutator( function: Callable[[Bundle, "Job"], "Job"],