I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!
GN tool that is used in Chromium to generate ninja files has much more restrictive language than CMake or make. And even its more complex features are mostly workarounds or escape hatches to deal with legacy setups.
Python went from setup.py to pyproject.toml, but pyproject.toml declares a build-system, which is another package which all the complex logic from setup.py.
Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.
That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.
If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.
Or to be more specific, issue isn't text/templating as such. It is a fine templating language for text.
But to use a text templating language to generate YAML, which is not only structured, making it a bad match for character based templating with no knowledge of syntax, but indentation-based, making the combination almost seem like a joke.
Helm charts must be the worst engineering solution I have seen in popular use. First time I saw it I didn't believe it, that this was something people did, for real.
I wouldn't say text/template is terribly weird per se, and it's quite reminiscent of Jinja. But what is awful is using a text templating language to generate yaml with the correct level of indentation, and that's where 75% of Helm's problems lie; the other 25% is putting too much logic in templates while working with the clumsy workarounds to text/template having no capability of defining custom functions.
there's a rare form of that where it goes from( simple -> programming language -> language with DSL support -> simple dsl ) ; emacs has followed this model a bit.
Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize.
I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.
> Make -> ninja
I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!
GN tool that is used in Chromium to generate ninja files has much more restrictive language than CMake or make. And even its more complex features are mostly workarounds or escape hatches to deal with legacy setups.
Python went from setup.py to pyproject.toml, but pyproject.toml declares a build-system, which is another package which all the complex logic from setup.py.
Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.
> Python setup.py -> pyproject.toml?
That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.
If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.
I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.
Or to be more specific, issue isn't text/templating as such. It is a fine templating language for text.
But to use a text templating language to generate YAML, which is not only structured, making it a bad match for character based templating with no knowledge of syntax, but indentation-based, making the combination almost seem like a joke.
Helm charts must be the worst engineering solution I have seen in popular use. First time I saw it I didn't believe it, that this was something people did, for real.
I wouldn't say text/template is terribly weird per se, and it's quite reminiscent of Jinja. But what is awful is using a text templating language to generate yaml with the correct level of indentation, and that's where 75% of Helm's problems lie; the other 25% is putting too much logic in templates while working with the clumsy workarounds to text/template having no capability of defining custom functions.
1 reply →
WirePlumber switched its config from Lua to a JSON variant not so long ago.
there's a rare form of that where it goes from( simple -> programming language -> language with DSL support -> simple dsl ) ; emacs has followed this model a bit.