-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
296 v1alpha1 #598
Closed
Closed
296 v1alpha1 #598
Conversation
This file contains 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
The pattern is <base>/<target> which allows for defining different spcificity levels as well as nice composition of different ident types. This initial commit defines different ident types as well as an AnyIdent with an optional build that replaces the old ident nearly everywhere. Next steps are to use more specific identifier types where applicable Signed-off-by: Ryan Bottriell <[email protected]>
This mean that the v0 spec type needed to be updated to be generic over the internal ident type, as well as the storage interfaces using the appropriate ident types for loading recipes vs packages. This was largely an exercise in refactoring and separating logic that used to be conditional on the presence of a build into distict functions instead. Signed-off-by: Ryan Bottriell <[email protected]>
Uses macros to share common 'inheritance' instead of having a deref implementation. This works better accross types where dereferencing to the base is not as useful as the target (eg located idents) but also creates a safer usage where ident types are not converted silently, instead needing an explicit conversion call by the developer. Additionally, add a HasLocation trait to complete the set. Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
There are still references to these types in the main package and recipe traits, but there should not be as they represent specific ways that the v0 spec did things Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Previously, embedded packages were assumed to be the enum spec type, which created an undesirable loop in the type hierearchy. Now, packages define their embedded stub type and it can be separate. This also extends to component specs, which also now are generic over the type of embedded package that they allow. Signed-off-by: Ryan Bottriell <[email protected]>
This changes the current inheritance mechanism from being calculated based on the specific v0::Opt::inheritance field, instead expecting the package itself to identify downstream requests that need to be present. In short, this means that users need to add explicit requests to satisfy the upstream packages. As much as this is more work for users, it ensures that the final nature of each one remains up to the package definition so that they can be based on when conditions and/or attached only to specific components which is not possible now. Signed-off-by: Ryan Bottriell <[email protected]>
This includes the initial implementation needed for validating if a when block has been satisfied or not Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
This allows the trait to replace a number of redundant arguments where solutions were already being passed which have access to the options from the solver as desired. Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
This removes the logic from the graph file and makes the function signature consistent with the others that retrieve requirements Signed-off-by: Ryan Bottriell <[email protected]>
The when conditions needed to be split out so that we could have a separate set of allowed conditions for build environments. Specifically, you cannot have build-time when condition that depends on packages in the build environment (that has not been resolved yet) Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Make the compatbility type serializable and then use it to track the reason for options being disabled dowstream in v1 packages (instead of booleans). Then, ensure that the components and defaults are properly handled when checking if options are active downstream. Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
The target identifies the package and version being built that the build environment was resolved for. This is needed for some conditionals to be able to check if the condition is for the current package or one that actually should have been resolved in the build environment itself. Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Signed-off-by: Ryan Bottriell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
agenda item
Items to be brought up at the next dev meeting
enhancement
New feature or request
unresolved
Closed but not completed
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.
Pushing my first working pass at the v1 spec version. I think there are still a few changes and tweaks that we can discuss for ease of use but so far it's working pretty well, and needs more hands-on to continue the conversation. The testing so far is largely manual, and I will circle back to fill out the unit tests when I have some more time.
The other changes that I've opened you'll see replicated here, and there are still more that I want to tease out. So for now, the diff is extra large and probably not worth reviewing as-is. I'd suggest building this version and trying out the spec format more than anything so that we can continue to refine it.
PRs that are more reviewable subsets of these changes:
spk lint
command #600Error
implementation forPkgRequest
#631impl Satisfy
for recipe types #632@source
#633TODO:
Variant
traitCloses #296