Support a way to escape the setter syntax

[mgoltzsche]

Problem

I want to deploy a kpt package using FluxCD but its variable substitution syntax clashes with kpt's setter syntax when both are used in the same field like in this example Deployment patch (that aims to enforce a redeployment when a secret name that is provided as substitution variable to a FluxCD Kustomization resource changes, falling back to a default Secret name that is maintained using a kpt setter, based on a blueprint):

...
        envFrom:
        - secretRef:
            name: ${APP_CONFIG_SECRET_NAME:=mopidy-defaults} # kpt-set: ${APP_CONFIG_SECRET_NAME:=${name}-defaults}

When running kpt fn render (using kpt 1.0.0-beta.32) in the root directory of the mopidy-container repo, it fails with the following output:

Package "mopidy-container": 
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.2.0"
[FAIL] "gcr.io/kpt-fn/apply-setters:v0.2.0" in 100ms
  Results:
    [error]: failed to apply setters: values for setters [${APP_CONFIG_SECRET_NAME:=mopidy-defaults}] must be provided
  Stderr:
    "values for setters [${APP_CONFIG_SECRET_NAME:=mopidy-defaults}] must be providedvalues for setters [${APP_CONFIG_SECRET_NAME:=mopidy-defaults}] must be provided"
  Exit code: 1

kpt apply-setters function interprets the FluxCD Kustomization variable expression as kpt setter variable.

Proposed solution

To disambiguate the syntax, kpt should support an escape character (such as \ or $; in absence of string literal expressions).
Using \ as escape character, a working version of the broken example snippet from above could look as follows:

...
        envFrom:
        - secretRef:
            name: ${APP_CONFIG_SECRET_NAME:=mopidy-defaults} # kpt-set: \${APP_CONFIG_SECRET_NAME:=${name}-defaults}

Workaround

Don't mix FluxCD variables with kpt setters within the same field and accept that the variable fallback value (for development) is static (same for every app that inherits the blueprint):

        envFrom:
        - secretRef:
            name: ${APP_NAME:=app}-defaultconfig
        - secretRef:
            name: ${APP_CONFIG_SECRET_NAME:=app-defaultconfig}

Thus, there is no urgent need to solve this issue but it would be nice to have.

[mortent]

Thanks for reporting this. It probably isn't at the top of our priorities at the moment, but we are open to contributions. It would also be interesting to think about how these scenarios would work without the dependence on setters, as they have some challenges as described in #3131.