From afa253c4317680562a05a961c22e47f365014702 Mon Sep 17 00:00:00 2001 From: Gleb Kanterov Date: Fri, 14 Mar 2025 10:41:42 +0100 Subject: [PATCH] [Python] Clarify rationale for mutator design (#2488) ## Changes Clarify rationale for design of `@job_mutator` --- .../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 2c35d9ca6..b871c0f3a 100644 --- a/experimental/python/databricks/bundles/core/_resource_mutator.py +++ b/experimental/python/databricks/bundles/core/_resource_mutator.py @@ -52,6 +52,20 @@ class ResourceMutator(Generic[_T]): """ +# 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"],