Add PklProvider

[jcubit]

Although Pkl can render configurations in JSON and YAML formats, it would be useful to be able to load Pkl configuration files directly. Pkl offers validation and its own resource readers in one place. You can also define your own custom resource readers. The pkl-swift bindings already exist, and this could be added under a Package trait.

[czechboy0]

Hi @jcubit,

yes I've heard from a few folks interested in pkl integration. Can you illustrate on an example how it would work? At a high level, I see two potentially integration points:

1. pkl-swift as a ConfigProvider implementation, which would allow skipping the rendering to JSON/YAML and allow Swift Configuration to read a pkl file directly to evaluate its values.
2. pkl-swift as the "UX", and it using Swift Configuration as a custom pkl "loader".

Which one are you thinking? Also cc @bioball

[jcubit]

Hi @czechboy0

I was thinking about option 1 and use pkl-swift as a ConfigProvider implementation to be able to read pkl files directly. Something analogous to the JSONProvider:

// This pkl evaluator options could be the default
let evaluatorOptions: EvaluatorOptions = .preconfigured 

// Load from a Pkl file
let provider = try await PklProvider(options: evaluatorOptions, filePath: "/etc/config.pkl")
let config = ConfigReader(provider: provider)

// Access nested values using dot notation
let host = config.string(forKey: "database.host")
let port = config.int(forKey: "database.port")
let isEnabled = config.bool(forKey: "features.enabled", default: false)

I think we want to wrap PklSwift.Evaluator or use the withEvaluator functions. AFAIK the expression evaluator provides the access to nested values.

I wonder if users of this provider could generate the respective configuration DTO via pkl-gen-swift if they want to unpack directly into an object. Does swift-configuration support a custom configuration content? I guess this is already supported via the ConfigContent.bytes and then the user would do the decoding into its custom type.

[czechboy0]

Yeah the above is part 1:

pkl-swift as a ConfigProvider implementation, which would allow skipping the rendering to JSON/YAML and allow Swift Configuration to read a pkl file directly to evaluate its values.

I think this is valuable on its own.

Regarding part 2:

pkl-swift as the "UX", and it using Swift Configuration as a custom pkl "loader".

that's what you're hinting at with:

I wonder if users of this provider could generate the respective configuration DTO via pkl-gen-swift if they want to unpack directly into an object.

I think 1 and 2 can be treated completely separately. They could even be hosted in two separate packages, though I suspect a good ultimate destination would be either pkl-swift itself, or a separate package swift-configuration-pkl or similar, hosted close to the pkl-swift code. One of the reasons why I don't expect us to land that code in this repo is to avoid circular dependencies - we want to allow those other repos to configure themselves using Swift Configuration.

[jcubit]

Right, this probably should be close to the pkl-swift repo in order to avoid circular dependencies

[bioball]

One of the reasons why I don't expect us to land that code in this repo is to avoid circular dependencies - we want to allow those other repos to configure themselves using Swift Configuration.

I'm not opposed to a separate repo, but I want to note that it's unlikely that pkl-swift will include swift-configuration as a library, since pkl-swift is also a configuration library.

I wonder if users of this provider could generate the respective configuration DTO via pkl-gen-swift if they want to unpack directly into an object

Good point, and this seems important; if you're already using pkl-swift, having code-generated structs is a key feature. It allows users to write this:

let host = config.database.host
let port = config.database.port

Instead of this:

let host = config.string(forKey: "database.host")
let port = config.int(forKey: "database.port")