-
Notifications
You must be signed in to change notification settings - Fork 494
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
feat: Add toYamlWithIndent template function #3875
base: master
Are you sure you want to change the base?
Conversation
Converting to draft and adding @bradenhilton as a reviewer re #3873 (reply in thread). Excellent comment. |
I haven't thought it through thoroughly, but could it be better implemented as a template directive, along with JSON and TOML, etc.? |
Hmm. TOML officially has no indenting (whitespace before key names is ignored). Sprig provides two functions I’m rambling here, because as nice as this would be, I don't think that either a directive or a new function really does the right thing — and the new function doesn't fix a problem with trying to render YAML inside a nested key (it wasn't requested, but is a bigger problem than the default indent level). To solve the original problem, I wonder if this might not just be better done as an option? With respect to "rendering in a nested key", I don't have any immediate examples as I’ve been trying to simplify my templates some, and there are issues with using $ chezmoi execute-template 'key:
value: {{ dict "a" "1" "b" "2" | toYaml}}'
key:
value: a: "1"
b: "2" Compared to: $ chezmoi execute-template 'key:
value: {{ dict "a" "1" "b" "2" | toJson }}'
key:
value: {"a":"1","b":"2"} Using $ chezmoi execute-template 'key:
value:
{{ dict "a" "1" "b" "2" | toYaml | indent 4}}'
key:
value:
a: "1"
b: "2" TL;DR: |
@halostatue I disagree with it being an option (at least instead of a directive). An option would be nice to provide a default for all files, though. Most of the time the formatting isn't important (with YAML being an exception to this, as you pointed out), which makes the files where it is important outliers, so to me it makes more sense to have it be a directive which is file-secific. Just to be clear, I wasn't suggesting adding a directive for each language, rather a more general
or similar, though I am aware that some languages don't support tab indentation, which would possibly require a directive for tab sizes that could be used to convert them to spaces. |
I can buy that, especially with |
c8ae27a
to
7a68dfc
Compare
Fixes #3873.
@vbrand1984 is this sufficient to solve your problem?