Open shiftyp opened 6 months ago
This seems like a hard problem. You would need to understand how a Pkl program turns into data, which is non-trivial. For example:
local nums = List(1, 2, 3)
pods {
for (num in nums) {
new Pod {
metadata {
name = "pod-\(num)"
}
}
}
}
output {
value = pods
renderer = new YamlRenderer {}
}
How would your wizard understand how to modify this program if, say, somebody adds a new pod?
In the use case I'm looking towards Pkl would be an intermediate format internal to the program, not ingested as an input. So, if the user were to add a pod it would be through the wizard itself, and the wizard would modify the underlying Pkl code, which would then output new manifests. Pkl is attractive as opposed to using plain YAML or JSON and a schema, because it has the potential to make the manifest generation within the wizard more easily maintainable,, testable, extensible, and migratable.
My thinking in the automation context is similar, where Pkl is generated and modified as an intermediate format, or an output format, but not an input format where the automation would need to reverse engineer user generated code. Does that answer the question?
I imagine there would be other use cases for AST traversal and modification (linting for example) that could ingest and make sense of user generated code however.
If you just want to be static content, you can use PcfRenderer
to produce it. Pcf is a static subset of Pkl. Adding a amends "mytemplate.pkl"
to the start of a .pcf
file (and renaming it to .pkl
) essentially gives you all validation right away (some caveats about polymorphism).
Purpose
I'd like to create a wizard application for managing kubernetes manifests, which reads and writes to a set of .pkl files. At the moment it's possible to read from a .pkl file and convert pkl types and primitives to language types and primitives, but I don't see any ability to then write and modify the underlying .pkl files.
Impact
This feature would open up new applications for Pkl in automation contexts. Many programs have wizards for example that create configuration files for users, or have the ability to maintain a configuration file as a feature. This addition to the language bindings would allow Pkl to be used in these contexts, increasing the number of appropriate use cases and adoption of the language.