Split Request to PinnableRequest and PinnedRequest#1297
Merged
Conversation
jrray
commented
Nov 30, 2025
| assert_eq!(req.to_string(), "test"); | ||
|
|
||
| install_spec | ||
| let install_spec = recipe_install_spec |
Collaborator
Author
There was a problem hiding this comment.
This is a good example of the new flow from recipe to package, since they are now different types rendering pins is not an in-place operation.
jrray
commented
Nov 30, 2025
Comment on lines
-701
to
-702
| spk_schema::ident::PinnableValue::FromBuildEnv => todo!(), | ||
| spk_schema::ident::PinnableValue::FromBuildEnvIfPresent => todo!(), |
Collaborator
Author
There was a problem hiding this comment.
I found these todo!s still hanging out, but in practice they are unreachable. Now the code path isn't possible.
5256ee2 to
186065d
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
8292908 to
cf80ac3
Compare
2 tasks
1d9a4a7 to
f2cefe8
Compare
80f5787 to
3de2d63
Compare
7cc4873 to
4954423
Compare
3de2d63 to
11ce6cb
Compare
ecfe0e7 to
0f0d853
Compare
e2c9d96 to
9236ac7
Compare
9236ac7 to
f0e01a8
Compare
dcookspi
approved these changes
Dec 12, 2025
Signed-off-by: J Robert Ray <jrray@jrray.org>
As this method always cloned self, per convention it should allow the caller to decide if it needs to clone or give up ownership. Admittedly there wasn't any existing code that could stop cloning. Signed-off-by: J Robert Ray <jrray@jrray.org>
This takes advantage of the work in #1295 in order to guarantee via types that var requirements have values in the context of a package requirements. The `PinnableRequest` type is what was previously called `Request`. This models what can appear in the install.requirements section of a recipe, as in: ```yaml # in a recipe install: requirements: - var: foo fromBuildEnv: true ``` When the package is built then a value must have been provided via options somewhere, and so the var becomes "pinned": ```yaml # in a package install: requirements: - var: foo/bar ``` While previously all code that operated on a `Request` would have to contend with the type allowing for the value to be missing (or not yet pinned), now a `PinnedRequest` is used that guarantees the value is present. This change also enforces via the type system that when a recipe is turned into a package that all the requirements are pinned. `PinnedRequest` did not get a different type for its `Pkg` variant (yet?), but it also has a similar pinned/unpinned concept. Signed-off-by: J Robert Ray <jrray@jrray.org>
f0e01a8 to
abc6052
Compare
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.
This takes advantage of the work in #1295 in order to guarantee via
types that var requirements have values in the context of a package
requirements.
The
PinnableRequesttype is what was previously calledRequest. Thismodels what can appear in the install.requirements section of a recipe,
as in:
When the package is built then a value must have been provided via
options somewhere, and so the var becomes "pinned":
While previously all code that operated on a
Requestwould have tocontend with the type allowing for the value to be missing (or not yet
pinned), now a
PinnedRequestis used that guarantees the value ispresent.
This change also enforces via the type system that when a recipe is
turned into a package that all the requirements are pinned. A related bug was recently discovered and fixed in #1302.
PinnedRequestdid not get a different type for itsPkgvariant(yet?), but it also has a similar pinned/unpinned concept.