I'm having a little trouble understanding the problem(s) Pkl is trying to solve.
After reading the title, my assumption was that Pkl was yet another newer, better configuration language (a la TOML), but now that I've read the article, it sounds like it's more a language for _generating_ config.
Unless I'm mistaken, it sounds like an abstraction on top of your config files meant to help you build & re-use configuration in a more standardized way, rather than yet another config language into itself.
A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.
Is Pkl designed to help address that sort of problem? Or am I missing something?
> A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.
Yes, Pkl is meant to solve this problem. It's a single place for you to configure all your targets. Within the same codebase, you can generate static configuration, and also import the same Pkl source files into a runtime application, so you don't have to copy/paste things around.
We do have a degree of abstraction through terraform modules, but I've found that the same copy-paste problem applies to the terraform that composes those modules together.
This is possibly (if not likely) moreso a result of creating our terraform modules in a suboptimal way due to insufficient expertise than a shortcoming of Terraform itself.
It is also largely a result of having a backlog of scheduled redactors that is longer than I'd care to admit.
It solves exactly the sort of problem you are describing, yes! I think the discussions here focus too much on the language bindings, but maybe I’m missing that point as well.
After reading the title, my assumption was that Pkl was yet another newer, better configuration language (a la TOML), but now that I've read the article, it sounds like it's more a language for _generating_ config.
Unless I'm mistaken, it sounds like an abstraction on top of your config files meant to help you build & re-use configuration in a more standardized way, rather than yet another config language into itself.
A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.
Is Pkl designed to help address that sort of problem? Or am I missing something?