feat: Pkl lang demo

[maxpushka]

Motivation

Pkl addresses several challenges commonly encountered with traditional configuration formats and general-purpose programming languages when managing configurations:

1. Limited expressiveness and reusability → tired of copy-pasting boilerplate configurations?

   • Formats like JSON, YAML, and XML often lack mechanisms for abstraction and code reuse, leading to repetitive and error-prone configurations. Pkl introduces features such as classes, functions, conditionals, and loops, enabling the creation of modular and reusable configuration components.

2. Validation and safety concerns → are you sure this JSON field can be omitted safely?

   • Traditional formats typically do not provide built-in validation, increasing the risk of deploying invalid configurations. Pkl incorporates a robust type system and validation capabilities, allowing developers to define schemas that enforce constraints and catch errors before deployment.

3. Scalability issues → drowning in a sea of ever-growing configurations?

   • Currently an average Ynet deployment uses 6-8 config files per environment (as per this PR: feat(networks): extract explicit terminal and vault configs #469), which is still a lot for the given project. As projects grow in complexity, managing configurations with static formats becomes cumbersome. Pkl is designed to scale from simple to complex use cases (just check how vastly blockchain.pkl differs from aa.pkl in networks/templates/!), providing necessary tools to handle intricate configurations efficiently.

4. Lack of advanced tooling → ever been lost in a maze of YAML files?

   • Static configuration formats often suffer from limited tooling support, making development and debugging more challenging. Pkl offers enhanced tooling, including IDE integrations with features like auto-complete, error highlighting, and inline documentation, improving the developer experience.

Impact

1. Maintainability through reuse, typing, templating, and abstraction
   • Avoid typos in JSON field names
   • If WebSocket URL is required, you can't pass HTTP URL
   • Enums (!)
   • Edit the config without accidentally kicking off a chain reaction that breaks the world
   • No need to sync default values in env-default struct tags across all services that the config is used in
2. Config validation — no need to duplicate validation in all environments that the config is used in (e.g. FE and multiple BE services). If the config is invalid, rendering fails immediately and sets an alarm on. If the config is committed, then it's definitely valid, and there's not need to double down on complex validations on the service side, though some may still be necessary
3. Rendering in any format a service requires
   1. All popular formats: JSON, YAML, TOML, Protobuf, XML, plist, CSV, you name it + one can implement renderers for custom formats
   2. OR use a single pkl struct tag. No need to keep a zoo of struct tags that span over the horizon for each field like json:"chain_ids" yaml:"chain_ids" env:"PATHFINDER_CHAIN_IDS" env-separator:"," env-default:"1,59144,137,534352"

POC scope

This PR moves to Pkl...

• Terminal configs for all environments
• a set of Local environment configs for Vault

A CI/CD pipeline is proposed as well to automatically re-render the configs in all necessary formats as changes are committed to networks/ directory specifically. For now pipeline renders Pkl to JSON only but it can be easily extended to render in multiple formats in one run.

Quickstart

How to render a single config (for demo purposes):

1. install Pkl on your machine
   1. MacOS: brew install pkl
   2. Linux: curl -L -o /usr/local/bin/pkl 'https://github.com/apple/pkl/releases/download/0.27.1/pkl-linux-amd64' && chmod +x /usr/local/bin/pkl
2. cd networks/terminal/hackathon
3. render configs
   1. pkl eval peers.pkl -f json
   2. pkl eval peers.pkl -f yaml
4. ???
5. profit!

TODOs (if POC is accepted)

• move preprod and prod configs to Pkl
• drop existing JSON configs
• move default values from clearsync/pkg/userop package config into networks/templates/aa.pkl
• Automation (GitHub Actions workflow)
  • replace username and email
  • drop underscore from name workflow dir name (.github/_workflows → .github/workflows). Reason: repo is protected to prohibit non-admin users to create workflows