I'm trying to prototype a plugin (my first one) and I'm confused how

FieldSet

matching work. I've created:

class MyGitopsHelmBundleTarget(Target):
    alias = "my_gitops_helm_bundle"
    core_fields = (
        *(FrozenOrderedSet(HelmDeploymentTarget.core_fields) - {HelmDeploymentCreateNamespaceField}),
        MyGitopsHelmBundleAppDirField,
        MyGitopsHelmBundleContextField
    )
@dataclass(frozen=True)
class MyGitopsHelmBundleFieldSet(FieldSet):
    required_fields = (
        HelmDeploymentDependenciesField,
        HelmDeploymentSourcesField,
        MyGitopsHelmBundleAppDirField,
        MyGitopsHelmBundleContextField
    )
  # ... fields here

My expectation is that if I do

pants experimental-deploy src/some_my_gitops_helm_bundle

then my plugin will do it's thing (will right now just log some warnings). Instead I'm seeing my the upstream helm backend and my plugin be invoked. This is confusing to me since the FieldSets have different required fields. (For context my plugin is conceptually another way to handle a helm "deployment". Instead of exec-ing out to the

helm

binary, I'm trying to make a tarball of the final yaml to pass off to an internal tool.)

It looks like

HelmDeploymentFieldSet

doesn't define an

opt_out

override, so I think there's no way to stop it picking up any target that has both

HelmDeploymentDependenciesField

and

HelmDeploymentSourcesField

fields. So one option might be to add (to upstream) a

skip_deploy

field or something and an

opt_out

method that checks it? I don't know if that's sensible, though

Thanks for the thoughts. I ended up adding a new goal to "deploy my way". What I'm doing is sort of like "package" but also sort of like "deploy" but neither exactly fits. I'm not sure what the general pattern should be. When you add a new linter you generally want to "run all the linters", but for deploying it's messier: • Probably not deploy in multiple ways? • Deploy in exactly one way? • Deploy in different ways based on configuration/environment?