I like the idea of Cue and I wanted to try using it to improve some of my system integration glue code - stuff that sucks in terse master config files and generates inputs for ansible and for various periodic ETL jobs.
But it seemed to me that Cue wanted to be in charge: I could see how to import an existing JSON or YAML file, converting it to Cue and committing it to the repo, but I could not work out how to load JSON or YAML as input data at run time.
I hope this is easier now, but when I tried it seemed to lack some basic command-line affordances that would make it usable in place of Python or jq.
Yeah, same experience. We had to write our own “terraform” like tooling to make use of it (retry loops and the like). It has (had? This was a couple years ago) no awareness, for example, of AWS, so out comes the SDK and Go.
“Why not just create templates with the SDK, constrain configurable fields with regex?”, I offered.
“CUE has typed feature structures!”, they said.
“FML.”, I thought.
It didn’t simplify configuration at all.
What simplifies configuration is all the people that know an existing tool and can be productive in it. As a late-comer CUE has none of that advantage.
Businesses want to solve business problems. Not meditate on one problem in perpetuity.
I’m not sure that CUE or any similar system can fix the essential reasons that configuration languages become hard to use.
A big problem with configuration parameters is understanding what they do. Typically you depend on the documentation and experimentation, which is okay for a text editor but more difficult when software gets more complex and abstract.
To find out what a function does, you can read its definition. But the meaning of a constant or a configuration parameter doesn’t come from its definition. It comes from the code that uses it. Typically, it could be used anywhere in the program, and the code could be of arbitrary complexity.
But users typically don’t read the source code at all, so basically you’re tweaking a global variable and you hope it does what you think.
Configuration files are written in little languages where each parameter has potentially global effect and the interactions between them is usually unspecified. We hope they’re orthogonal, but this depends on the good taste of the language designer. When constants get turned into configuration parameters on an ad-hoc basis, this language is unlikely to be designed well.
What I wanted from Cue was a way to set structured config parameters in one place (eg, my server roles, host names, and IP addresses) and populate the various config files that need that information, with a bit more typefulness than yaml and jinja.
[I look after DNS servers so the setup is relatively static, but I would like to make it a lot easier to spin up temporary test instances, which needs a more loosely coupled config setup.]
4 comments
[ 4.7 ms ] story [ 19.5 ms ] threadBut it seemed to me that Cue wanted to be in charge: I could see how to import an existing JSON or YAML file, converting it to Cue and committing it to the repo, but I could not work out how to load JSON or YAML as input data at run time.
I hope this is easier now, but when I tried it seemed to lack some basic command-line affordances that would make it usable in place of Python or jq.
“Why not just create templates with the SDK, constrain configurable fields with regex?”, I offered.
“CUE has typed feature structures!”, they said.
“FML.”, I thought.
It didn’t simplify configuration at all.
What simplifies configuration is all the people that know an existing tool and can be productive in it. As a late-comer CUE has none of that advantage.
Businesses want to solve business problems. Not meditate on one problem in perpetuity.
A big problem with configuration parameters is understanding what they do. Typically you depend on the documentation and experimentation, which is okay for a text editor but more difficult when software gets more complex and abstract.
To find out what a function does, you can read its definition. But the meaning of a constant or a configuration parameter doesn’t come from its definition. It comes from the code that uses it. Typically, it could be used anywhere in the program, and the code could be of arbitrary complexity.
But users typically don’t read the source code at all, so basically you’re tweaking a global variable and you hope it does what you think.
Configuration files are written in little languages where each parameter has potentially global effect and the interactions between them is usually unspecified. We hope they’re orthogonal, but this depends on the good taste of the language designer. When constants get turned into configuration parameters on an ad-hoc basis, this language is unlikely to be designed well.
[I look after DNS servers so the setup is relatively static, but I would like to make it a lot easier to spin up temporary test instances, which needs a more loosely coupled config setup.]