Do not read version/name from pkl_project#120
Merged
sitaktif merged 1 commit intoapple:mainfrom Nov 24, 2025
Merged
Conversation
78c435a to
09e515f
Compare
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.
09e515f to
66e4920
Compare
gibfahn
approved these changes
Nov 24, 2025
KushalP
approved these changes
Nov 24, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 (viapkl 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: theversionattribute was removed, and the user can use theextra_flagsattribute 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_packagetarget now returns a directory output, and the path to the packaged pkl project ends up in a subdirectory.