Skip to content

Do not read version/name from pkl_project#120

Merged
sitaktif merged 1 commit intoapple:mainfrom
sitaktif:pkl-package-late-eval
Nov 24, 2025
Merged

Do not read version/name from pkl_project#120
sitaktif merged 1 commit intoapple:mainfrom
sitaktif:pkl-package-late-eval

Conversation

@sitaktif
Copy link
Copy Markdown
Collaborator

Previously, we relied on the PklProject name and version fields to be passed via a provider so that the pkl_project rules could determine at analysis time the name of output files that will be generated.

Now, pkl_project generates an output directory instead, and that rule is the one that is responsible to evaluating name and version from the PklProject file.

This solves a problem we had in the past where the PklProject pkl content was evalutated twice: once by pkl_project (via pkl eval) and once by pkl_package (via pkl project package), sometimes ending up in different evaluations, if e.g. env vars were different between the two.

This also solves the problem of having to ensure there aren't any discrepancies between the version evaluated in the PklProject and the one passed as an attribute to pkl_package: the version attribute was removed, and the user can use the extra_flags attribute instead, e.g. extra_flags = ["--env-var=MY_VERSION=1.2.3"] (which has the advantage of working with Pkl properties and any other kind of parametrization that may arise in Pkl in the future).

BREAKING CHANGES: The provider API changed. A pkl_package target now returns a directory output, and the path to the packaged pkl project ends up in a subdirectory.

@sitaktif sitaktif force-pushed the pkl-package-late-eval branch from 78c435a to 09e515f Compare November 19, 2025 10:49
Previously, we relied on the PklProject name and version fields to be
passed via a provider so that the pkl_project rules could determine at
analysis time the name of output files that will be generated.

Now, pkl_project generates an output directory instead, and that rule is
the one that is responsible to evaluating name and version from the
PklProject file.

This solves a problem we had in the past where the PklProject pkl
content was evalutated twice: once by pkl_project (via `pkl eval`) and
once by pkl_package (via `pkl project package`), sometimes ending up in
different evaluations, if e.g. env vars were different between the two.

This also solves the problem of having to ensure there aren't any
discrepancies between the version evaluated in the PklProject and the
one passed as an attribute to `pkl_package`: the `version` attribute was
removed, and the user can use the `extra_flags` attribute instead, e.g.
`extra_flags = ["--env-var=MY_VERSION=1.2.3"]` (which has the advantage
of working with Pkl properties and any other kind of parametrization
that may arise in Pkl in the future).

BREAKING CHANGES: The provider API changed. A `pkl_package` target now
returns a directory output, and the path to the packaged pkl project
ends up in a subdirectory.
@sitaktif sitaktif force-pushed the pkl-package-late-eval branch from 09e515f to 66e4920 Compare November 21, 2025 09:24
@sitaktif sitaktif merged commit 76d974b into apple:main Nov 24, 2025
4 checks passed
@sitaktif sitaktif deleted the pkl-package-late-eval branch November 24, 2025 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants