CLI

The pkl command-line interface (CLI) evaluates Pkl modules and writes their output to the console or a file. For interactive development, the CLI includes a Read-Eval-Print Loop (REPL).

Installation

The CLI comes in multiple flavors:

Native macOS executable for amd64 (tested on macOS 10.15)
Native Linux executable for amd64
Native Linux executable for aarch64
Native Alpine Linux executable for amd64 (cross-compiled and tested on Oracle Linux 8)
Java executable (tested with Java 11/17 on macOS and Oracle Linux)

On macOS and Linux, we recommend using the native executables. They are self-contained, start up instantly, and run complex Pkl code much faster than the Java executable.

What is the Difference Between the Linux and Alpine Linux Executables?

The Linux executable is dynamically linked against glibc and libstdc++, whereas, the Alpine Linux executable is statically linked against musl libc and libstdc++.

The Java executable works on multiple platforms and has a smaller binary size than the native executables. However, it requires a Java 11 (or higher) runtime on the system path, has a noticeable startup delay, and runs complex Pkl code slower than the native executables.

All flavors are built from the same codebase and undergo the same automated testing. Except where noted otherwise, the rest of this page discusses the native executables.

Homebrew

Release versions can be installed with Homebrew.

To install Pkl, run:

brew install pkl

To update Pkl, run:

brew update
brew upgrade pkl   # or just `brew upgrade`

Download

Development and release versions can be downloaded and installed manually.

macOS Executable

On aarch64:

curl -L -o pkl https://github.com/apple/pkl/releases/download/0.25.3/pkl-macos-aarch64
chmod +x pkl
./pkl --version

On amd64:

curl -L -o pkl https://github.com/apple/pkl/releases/download/0.25.3/pkl-macos-amd64
chmod +x pkl
./pkl --version

This should print something similar to:

Pkl 0.25.3 (macOS, native)

Linux Executable

The Linux executable is dynamically linked against glibc and libstdc++ for the amd64 and aarch64 architectures. For a statically linked executable, see Alpine Linux Executable.

On aarch64:

curl -L -o pkl https://github.com/apple/pkl/releases/download/0.25.3/pkl-linux-aarch64
chmod +x pkl
./pkl --version

On amd64:

curl -L -o pkl https://github.com/apple/pkl/releases/download/0.25.3/pkl-linux-amd64
chmod +x pkl
./pkl --version

This should print something similar to:

Pkl 0.25.3 (Linux, native)

Alpine Linux Executable

The Alpine Linux executable is statically linked against musl libc and libstdc++. For a dynamically linked executable, see Linux Executable.

curl -L -o pkl https://github.com/apple/pkl/releases/download/0.25.3/pkl-alpine-linux-amd64
chmod +x pkl
./pkl --version

This should print something similar to:

Pkl 0.25.3 (Linux, native)

We currently do not support the aarch64 architecture for Alpine Linux.

Java Executable

curl -L -o jpkl https://repo1.maven.org/maven2/org/pkl-lang/pkl-cli-java/0.25.3/pkl-cli-java-0.25.3.jar
chmod +x jpkl
./jpkl --version

This should print something similar to:

Pkl 0.25.3 (macOS 10.16, Java 11.0.9)

Usage

Synopsis: pkl <subcommand> [<options>] [<args>]

For a brief description of available options, run pkl -h.

The Java executable is named jpkl.

`pkl eval`

Synopsis: pkl eval [<options>] [<modules>]

Evaluate the given Pkl <modules> and produce their rendering results.

<modules>: The absolute or relative URIs of the modules to evaluate. Relative URIs are resolved against the working directory.

Options

-f, --format

Default: (none)
Example: yaml
The output format to generate. The default output renderer for a module supports the following formats:

json
jsonnet
pcf
plist
properties
textproto
xml
yaml

If no format is set, the default renderer chooses pcf.

-o, --output-path

Default: (none)
Example: "config.yaml"
The file path where the output file is placed. Relative paths are resolved against the project directory.

This option is mutually exclusive with --multiple-file-output-path. If neither option is set, each module’s output.text is written to standard output.

If multiple source modules are given, placeholders can be used to map them to different output files. The following placeholders are supported:

%{moduleDir}: The directory path of the module, relative to the working directory. Only available when evaluating file-based modules.
%{moduleName}: The simple module name as inferred from the module URI. For hierarchical URIs such as file:///foo/bar/baz.pkl, this is the last path segment without file extension.
%{outputFormat}: The requested output format. Only available if --format is set.

If multiple source modules are mapped to the same output file, their outputs are concatenated. By default, module outputs are separated with ---, as in a YAML stream. The separator can be customized using the --module-output-separator option.

--module-output-separator

Default: --- (as in a YAML stream)
The separator to use when multiple module outputs are written to the same file, or to standard output.

-m, --multiple-file-output-path

Default: (none)
Example: "output/"
The directory where a module’s output files are placed.

Setting this option causes Pkl to evaluate a module’s output.files property and write the files specified therein. Within output.files, a key determines a file’s path relative to --multiple-file-output-path, and a value determines the file’s contents.

This option cannot be used together with any of the following:

--output-path
--expression

This option supports the same placeholders as --output-path.

Examples:

# Write files to `output/`
pkl eval -m output/ myFiles.pkl

# Write files to the current working directory
pkl eval -m . myFiles.pkl

# Write foo.pkl's files to the `foo` directory, and bar.pkl's files
# to the `bar` directory
pkl eval -m "%{moduleName}" foo.pkl bar.pkl

For additional details, see Multiple File Output in the language reference.

-x, --expression

Default: (none)
The expression to be evaluated within the module.

This option causes Pkl to evaluate the provided expression instead of the module’s output.text or output.files properties. The resulting value is then stringified, and written to either standard out, or the designated output file.

For example, consider the following Pkl module:

pigeon.pkl

metadata {
  species = "Pigeon"
}

The following command prints Pigeon to the console:

pkl eval -x metadata.species pigeon.pkl
# => Pigeon

Setting an --expression flag can be thought of as substituting the expression in place of a module’s output.text property. Running the previous command is conceptually the same as if the below module were evaluated without the --expression flag:

metadata {
  species = "Pigeon"
}

output {
  text = metadata.species.toString()
}

This command also takes common options.

`pkl server`

Synopsys: pkl server

Run as a server that communicates over standard input/output.

This option is used for embedding Pkl in an external client, such as pkl-swift or pkl-go.

`pkl test`

Synopsys: pkl test [<options>] [<modules>]

Evaluate the given <modules> as tests, producing a test report and appropriate exit code.

Renderers defined in test files will be ignored by the test command.

<modules>: The absolute or relative URIs of the modules to test. Relative URIs are resolved against the working directory.

Options

--junit-reports

Default: (none)
Example: ./build/test-results
Directory where to store JUnit reports.

No JUnit reports will be generated if this option is not present.

--overwrite

Force generation of expected examples.
The old expected files will be deleted if present.

This command also takes common options.

`pkl repl`

Synopsys: pkl repl [<options>]

Start a REPL session.

This command takes common options.

`pkl project package`

Synopsis: pkl project package <project-dir>

This command prepares a project to be published as a package. Given a project directory, it creates the following artifacts:

<name>@<version> - the package metadata file
<name>@<version>.sha256 - the dependency metadata file’s SHA-256 checksum
<name>@<version>.zip - the package archive
<name>@<version>.zip.sha256 - the package archive’s SHA-256 checksum

These artifacts are expected to be published to an HTTPS server, such that the metadata and zip files can be fetched at their expected locations.

The package ZIP should be available at the packageZipUrl location specified in the PklProject file The package metadata should be available at the package URI’s derived HTTPS URL. For example, given package package://example.com/mypackage@1.0.0, the metadata file should be published to https://example.com/mypackage@1.0.0.

During packaging, this command runs these additional steps:

Run the package’s API tests, if any are defined.
Validates that if the package has already been published, that the package’s metadata is identical. This step can be skipped using the --skip-publish-check flag.

Examples:

# Search the current working directory for a project, and package it.
pkl project package

# Package all projects within the `packages/` directory to `.out`, writing each package's artifacts to its own directory.
pkl project package --output-path ".out/%{name}@%{version}/" packages/*/

Options

--output-path

Default: .out

The directory to write artifacts to. Accepts the following placeholders:

%{name}: The name of the package
%{version}: The version of the package

--skip-publish-check

Skips checking whether a package has already been published with different contents.

By default, the packager will check whether a package at the same version has already been published. If the package has been published, it validates that the package’s metadata is identical to the locally generated metadata.

--junit-reports

Default: (none)
Example: ./build/test-results
Directory where to store JUnit reports.

No JUnit reports will be generated if this option is not present.

--overwrite

Force generation of expected examples.
The old expected files will be deleted if present.

This command also takes common options.

`pkl project resolve`

Synopsis: pkl project resolve <project-dir>

This command takes the dependencies of a project, and writes the resolved versions a file at path PklProject.deps.json.

It builds a dependency list, taking the latest minor version in case of version conflicts. For more details, see the resolving dependencies section of the language reference.

Examples:

# Search the current working directory for a project, and resolve its dependencies.
pkl project resolve

# Resolve dependencies for all projects within the `packages/` directory.
pkl project resolve packages/*/

Options

This command accepts common options.

`pkl download-package`

Synopsis: pkl download-package <package-uri>

This command downloads the specified packages to the cache directory. If the package already exists in the cache directory, this command is a no-op.

Options

This command accepts common options.

Common options

The pkl eval, pkl test, pkl repl, pkl project resolve, pkl project package, and pkl download-package commands support the following common options:

--allowed-modules

Default: pkl:,file:,modulepath:,https:,repl:,package:,projectpackage:
Comma-separated list of URI patterns that determine which modules can be loaded and evaluated. Patterns are matched against the beginning of module URIs. (File paths have been converted to file: URLs at this stage.) At least one pattern needs to match for a module to be loadable. Both source modules and transitive modules are subject to this check.

--allowed-resources

Default: env:,prop:,package:,projectpackage:
Comma-separated list of URI patterns that determine which external resources can be read. Patterns are matched against the beginning of resource URIs. At least one pattern needs to match for a resource to be readable.

--cache-dir

Default: ~/.pkl/cache
Example: /path/to/module/cache/
The cache directory for storing packages.

--no-cache

Disable cacheing of packages.

-e, --env-var

Default: OS environment variables for the current process
Example: MY_VAR=myValue
Sets an environment variable that can be read by Pkl code with read("env:<envVarName>"). Repeat this option to set multiple environment variables.

-h, --help

Display help information.

--module-path

Default: (empty)
Example: dir1:zip1.zip:jar1.jar
Directories, ZIP archives, or JAR archives to search when resolving modulepath: URIs. Paths are separated by the platform-specific path separator (: on *nix, ; on Windows). Relative paths are resolved against the working directory.

-p, --property

Default: (none)
Example: myProp=myValue
Sets an external property that can be read by Pkl code with read("prop:<propertyName>"). Repeat this option to set multiple external properties.

--root-dir

Default: (none)
Example: /some/path
Root directory for file: modules and resources. If set, access to file-based modules and resources is restricted to those located under the specified root directory. Any symlinks are resolved before this check is performed.

--settings

Default: (none)
Example: mySettings.pkl
File path of the Pkl settings file to use. If not set, ~/.pkl/settings.pkl or defaults specified in the pkl.settings standard library module are used.

-t, --timeout

Default: (none)
Example: 30
Duration, in seconds, after which evaluation of a source module will be timed out. Note that a timeout is treated the same as a program error in that any subsequent source modules will not be evaluated.

-v, --version

Display version information.

-w, --working-dir

Base path that relative module paths passed as command-line arguments are resolved against. Defaults to the current working directory.

--ca-certificates

Default: (none)
Example: /some/path/certificates.pem
Path to a file containing CA certificates to be used for TLS connections.

Setting this option replaces the existing set of CA certificates bundled into the CLI. Certificates need to be X.509 certificates in PEM format.

For other methods of configuring certificates, see CA Certificates.

The pkl eval, pkl test, pkl repl, and pkl download-package commands also take the following options:

--project-dir

Default: (none)
Example: /some/path
Directory where the project lives.

A project is a directory that contains a PklProject file, which is used to declare package dependencies, as well as common evaluator settings to be applied in the project.

If omitted, this is determined by searching up from the working directory for a directory that contains a PklProject file, until --root-dir or the file system root is reached.

--omit-project-settings

Disables loading evaluator settings from the PklProject file.

--no-project

Disables all behavior related to projects.

Evaluating Modules

Say we have the following module:

config.pkl

bird {
  species = "Pigeon"
  diet = "Seeds"
}
parrot = (bird) {
  species = "Parrot"
  diet = "Berries"
}

To evaluate this module and write its output to standard output, run:

pkl eval config.pkl

You should see the following output:

bird {
  species = "Pigeon"
  diet = "Seeds"
}
parrot {
  species = "Parrot"
  diet = "Berries"
}

To render output as JSON, YAML, XML property list, or Java properties, use --format json, --format yaml, --format plist, or --format properties, respectively.

To control the output format from within Pkl code, see Module Output.

To read a source module from standard input rather than a file, use - as a module name:

echo mod2.pkl | pkl eval mod1.pkl - mod3.pkl

This is especially useful in environments that don’t support /dev/stdin.

To write output to a file rather than standard output, use --output-path some/file.ext.

Batch Evaluation

Multiple modules can be evaluated at once:

pkl eval config1.pkl config2.pkl config3.pkl

To write module outputs to separate output files, --output-path supports the following placeholders:

%{moduleDir}: the directory path of the source module, relative to the working directory (only available for file based modules)
%{moduleName}: the last path segment of the module URI, without file extension
%{outputFormat}: the target format (only available if --format is set)

The following run produces three JSON files placed next to the given source modules:

pkl eval --format=json --output-path=%{moduleDir}/%{moduleName}.json config1.pkl config2.pkl config3.pkl

If multiple module outputs are written to the same file, or to standard output, their outputs are concatenated. By default, module outputs are separated with ---, as in a YAML stream. The separator can be customized using the --module-output-separator option.

Working with the REPL

To start a REPL session, run pkl repl:

$ pkl repl
Welcome to Pkl 0.25.3.
Type an expression to have it evaluated.
Type :help or :examples for more information.

pkl>

The Java executable is named jpkl.

Loading Modules

To load config.pkl into the REPL, run:

pkl> :load config.pkl

To evaluate the bird.species property, run:

pkl> bird.species
"Pigeon"

To evaluate the entire module, force-evaluate this:

pkl> :force this

REPL Commands

Commands start with : and can be tab-completed:

pkl> :Tab
clear       examples    force       help        load        quit        reset
pkl> :qTab
pkl> :quitReturn
$

Commands can be abbreviated with any unique name prefix:

pkl> :qReturn
$

To learn more about each command, run the :help command.

Some commands support further command-specific tab completion. For example, the :load command supports completing file paths.

With commands out of the way, let’s move on to evaluating code.

Evaluating Code

To evaluate an expression, type the expression and hit Return.

pkl> 2 + 4
6

Apart from expressions, the REPL also accepts property, function, and class definitions. (See the Language Reference to learn more about these language concepts.)

pkl> hello = "Hello, World!"
pkl> hello
"Hello, World!"
pkl> function double(n) = 2 * n
pkl> double(5)
10
pkl> class Bird { species: String }
pkl> new Bird { species = "Pigeon" }
{
  name = ?
}

Top-level expressions are only supported in the REPL. In a regular module, every expression is contained in a definition, and only definitions exist at the top level.

Redefining Members

Existing members can be redefined:

pkl> species = "Pigeon"
pkl> species
"Pigeon"
pkl> species = "Barn"
pkl> species
"Barn"
pkl> species + " Owl"
pkl> species
"Barn Owl"

Due to Pkl’s late binding semantics, redefining a member affects dependent members:

pkl> name = "Barn"
pkl> species = "\(name) Owl"
pkl> species
"Barn Owl"
pkl> name = "Elf"
pkl> species
"Elf Owl"

Redefining members is only supported in the REPL. Under the hood, it works as follows:

The REPL environment is represented as a synthetic Pkl module.
When a new member is defined, it is added to the current REPL module.
When an existing member is redefined, it is added to a new REPL module that amends the previous REPL module.

Settings File

The Pkl settings file allows to customize the CLI experience.

A settings file is a Pkl module amending the pkl.settings standard library module. Its default location is ~/.pkl/settings.pkl. To use a different settings file, set the --settings command line option, for example --settings mysettings.pkl. To enforce default settings, use --settings pkl:settings. The settings file is also honored by (and configurable through) the Gradle plugin and CliEvaluator API.

Here is a typical settings file:

~/.pkl/settings.pkl

amends "pkl:settings" (1)

editor = Idea (2)

1	A settings file should amend the `pkl.settings` standard library module.
2	Configures IntelliJ IDEA as the preferred editor. Other supported values are `System`, `GoLand`, `TextMate`, `Sublime`, `Atom`, and `VsCode`.

With the above settings file in place, Cmd+Double-clicking a source code link in a stack trace opens the corresponding file in IntelliJ IDEA at the correct location.

To learn more about available settings, see pkl.settings.

CA Certificates

When making TLS requests, Pkl comes with its own set of CA certificates. These certificates can be overridden via either of the two options:

Set them directly via the CLI option --ca-certificates <path>.
Add them to a directory at path ~/.pkl/cacerts/.

Both these options will replace the default CA certificates bundled with Pkl.
The CLI option takes precedence over the certificates in ~/.pkl/cacerts/.
Certificates need to be X.509 certificates in PEM format.