Skip to content
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
wants to merge 69 commits into from
Closed

296 v1alpha1 #598

wants to merge 69 commits into from

Conversation

rydrman
Copy link
Collaborator

@rydrman rydrman commented Dec 23, 2022

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:

TODO:

  • pull out packages/Makefile fixes & improvements
  • pull out build env target changes into Expand BuildEnv trait to include options, target and used components #567
  • pull out error impl changes for pkgrequest
  • pull out the deletion of unused code
  • pull out the addition of lint command
  • pull out exact version matching for @sources
  • pull out unstable API publishing check
  • pull out the formalization of a Variant trait
  • pull out solution efficiency changes
  • replicate solve tests for v1 spec
  • add tests for bugs fixed through manual testing

Closes #296

rydrman and others added 30 commits November 15, 2022 13:01
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]>
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]>
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]>
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]>
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]>
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]>
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]>
@rydrman rydrman added enhancement New feature or request agenda item Items to be brought up at the next dev meeting labels Dec 23, 2022
@rydrman rydrman added this to the V1 Spec milestone Dec 23, 2022
@rydrman rydrman requested review from jrray and dcookspi December 23, 2022 20:41
@rydrman rydrman self-assigned this Dec 23, 2022
@rydrman rydrman added the unresolved Closed but not completed label Feb 14, 2024
@rydrman rydrman closed this Feb 14, 2024
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant