Open chrishumanitec opened 2 weeks ago
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: https://github.com/hashicorp/consul-template/pull/615
TODO more
Two things we could do while testing/figuring this out:
apiVersion: score.dev/v1b1
metadata:
name: my-workload
annotations:
compose.score.dev/experiment-placeholder-delimiters: "%{ }"
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.
$
with another character. E.g%
for%{...}
style placeholders.<<
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