[feat] Add abstract syntax tree modification and write to .pkl file capabilities to language bindings #84

New Issue

adam · 2025-12-30T01:20:32+01:00

adam commented

2025-12-30 01:20:32 +01:00

Originally created by @shiftyp on GitHub (Feb 20, 2024).

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.

Originally created by @shiftyp on GitHub (Feb 20, 2024). ## 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.

adam commented

2025-12-30 01:20:33 +01:00

@bioball commented on GitHub (Feb 22, 2024):

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?

@bioball commented on GitHub (Feb 22, 2024): This seems like a hard problem. You would need to understand how a Pkl program turns into data, which is non-trivial. For example: ```ts 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?

adam commented

2025-12-30 01:20:33 +01:00

@shiftyp commented on GitHub (Feb 22, 2024):

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?

@shiftyp commented on GitHub (Feb 22, 2024): 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?

adam commented

2025-12-30 01:20:34 +01:00

@shiftyp commented on GitHub (Feb 22, 2024):

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.

@shiftyp commented on GitHub (Feb 22, 2024): 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.

adam commented

2025-12-30 01:20:34 +01:00

@holzensp commented on GitHub (Mar 12, 2024):

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).

@holzensp commented on GitHub (Mar 12, 2024): 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).

adam referenced this issue

2025-12-30 01:24:19 +01:00

[PR #84] [MERGED] update 'Loading Modules' example to match config contents #403

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#84