Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Custom placeholder patterns in files #108

Open
chrishumanitec opened this issue Nov 4, 2024 · 2 comments
Open

[FEATURE] Custom placeholder patterns in files #108

chrishumanitec opened this issue Nov 4, 2024 · 2 comments
Labels
new feature/idea New feature or request

Comments

@chrishumanitec
Copy link

chrishumanitec commented Nov 4, 2024

Detailed description

When using the files feature in Score, it is often useful to embed placeholders. Unfortunately, the placeholder syntax in Score ${...} is very commonly used and so can result in ambiguities.

It is possible to escape all of the other non-score placeholders, but this results in potentially major changes to a config file just to adopt score. A better approach would be to be able to define a custom pattern for a placeholder in a file - for example %{...} that could leave the existing file intact except for actual score placeholders.

Examples for config files that use ${...} as a variable expansion pattern:

Context

Adopting score should not require major changes to existing configuration - for example escaping existing variable expansions. This could for example mean that the configuration file does not work with existing local tooling.

This only makes sense for files rather than variables - as variables are only in the score of the score file anyway.

NOTE Score already supports noExpand on the files object to avoid processing placeholders.

Possible implementation

There are a number of approaches that could be taken.

  1. Allow changing of the leading $ with another character. E.g % for %{...} style placeholders.
  2. Supply start and end placeholders entirely. E.g. << and >> for <<...>> style placeholders.

1 is simpler but 2 is more flexible as there could be unforseen situations where { is an integral part of the configuration language and a non overlapping prefix cannot be ruled out.

Additional information

No response

@astromechza astromechza added the new feature/idea New feature or request label Nov 11, 2024
@astromechza
Copy link
Member

Interesting. Prior art I've found are things like:

Go text/template

Go template language allows the delimiters to be set at the Parser level: https://pkg.go.dev/text/template#Template.Delims. This applies across all Go template files involved in simultaneous interpretation and cannot be turned on and off per template. Since Score allows team A to pull in a Score file published by team B, we would need to support this per Score file to avoid mandating the same delimiters.

Consul, a user of text/template, did a similar thing to expose this: hashicorp/consul-template#615

** TODO more **

@astromechza
Copy link
Member

Two things we could do while testing/figuring this out:

  1. Generalize the placeholders lib in score-go to support custom delimeters. Would we still support escaping a placeholder?
  2. Implement a score metadata annotation in score-compose that allows these delimiters to be set.
apiVersion: score.dev/v1b1
metadata:
  name: my-workload
  annotations:
    compose.score.dev/experiment-placeholder-delimiters: "%{ }"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature/idea New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants