-
Notifications
You must be signed in to change notification settings - Fork 99
path: Introduce package with initial tftypes.AttributePath abstraction #390
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
Conversation
Reference: #81 Reference: #161 Reference: #215 Reference: #365 This introduces a native abstraction over terraform-plugin-go's `tftypes.AttributePath`, allowing the framework to own the implementation details and extend the functionality further. Provider developers will be closer to removing a direct dependency on terraform-plugin-go. This is a major breaking change, however it is necessary before 1.0 to prevent compatibility issues in the future. This functionality is only intended to replace `tftypes.AttributePath` usage and not mess with the `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` type `tftypes.Value` data storage fields or their underlying data manipulation logic. This does leave the framework in an awkward half-state until those are further refactored (likely towards native `attr.Value`), but is done to try and reduce the review complexity of this initial migration. Additional followup changes will introduce the concept of path expressions, which will allow provider developers to match against multiple paths or reference parent paths in schema-based plan modifier and validation functionality. To prevent import cycles between `attr` and `diag` packages due changing the `attr.TypeWithValidate` type `Validate` method signature from `Validate(context.Context, tftypes.Value, *tftypes.AttributePath) diag.Diagnostics` to `Validate(context.Context, tftypes.Value, path.Path) diag.Diagnostics`, the `TypeWithValidation` interface is moved a new `xattr` package underneath `attr` with Go and website documentation to direct provider developers to the other package. This will also solve a prior issue with trying to implement `TypeWithModifyPlan` support. Naming and location of anything in this initial implementation can be adjusted as necessary. Provider developers can migrate to the new path handling by replacing: ```go tftypes.NewAttributePath().WithAttributeName("example") ``` With the equivalent: ```go path.RootPath("example") ``` Then using the `(Path).At*` methods to extend the path definition instead of `(*tftypes.AttributePath).With*` methods: | Current | New | | ------------------------ | --------------- | | `WithAttributeName()` | `AtName()` | | `WithElementKeyInt()` | `AtListIndex()` | | `WithElementKeyString()` | `AtMapKey()` | | `WithElementKeyValue()` | `AtSetValue()` |
bendbennett
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only looked through the path pkg, but that LGTM.
path/path.go
Outdated
| // EmptyPath creates an empty attribute path. Provider code should use | ||
| // RootPath. | ||
| func EmptyPath() Path { | ||
| return Path{ | ||
| steps: PathSteps{}, | ||
| } | ||
| } | ||
|
|
||
| // RootPath creates a new attribute path starting with a root | ||
| // PathStepAttributeName. | ||
| func RootPath(rootAttributeName string) Path { | ||
| return Path{ | ||
| steps: PathSteps{ | ||
| PathStepAttributeName(rootAttributeName), | ||
| }, | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given it worked out that this could be in its own package, I wonder if its worth shortening these these to just path.Root(string) and path.Empty()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big fan of short names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll update and push up, one second
detro
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this a lot.
Especially the hierarchy and combination of Path and PathStep, I find it quite elegant.
The builder-patterns to compose Paths is also quite concise and expressive, leading to smaller lines of code.
The CI is failing, probably a place where the replacement is still needed, but feels easy to fix:
Run go test -v ./internal/framework5provider
# github.com/hashicorp/terraform-provider-corner/internal/framework5provider [github.com/hashicorp/terraform-provider-corner/internal/framework5provider.test]
Error: internal/framework5provider/resource_user.go:[1](https://github.com/hashicorp/terraform-plugin-framework/runs/6995717727?check_suite_focus=true#step:8:1)99:90: cannot use tftypes.NewAttributePath().WithAttributeName("name") (type *tftypes.AttributePath) as type path.Path in argument to tfsdk.ResourceImportStatePassthroughID
FAIL github.com/hashicorp/terraform-provider-corner/internal/framework[5](https://github.com/hashicorp/terraform-plugin-framework/runs/6995717727?check_suite_focus=true#step:8:6)provider [build failed]
FAIL
Error: Process completed with exit code 2.
|
Updated the "starter" functions to just |
|
Downstream terraform-provider-corner updates: hashicorp/terraform-provider-corner#73 |
|
If anyone has any additional feedback on these changes, please reach out to me and we can go through it together before the next release. I'll also ensure terraform-provider-corner is pointing at main after merge so CI keeps working. |
* Update module github.com/hashicorp/terraform-plugin-log to v0.6.0 * Update module github.com/hashicorp/terraform-plugin-go to v0.12.0 * Update module github.com/hashicorp/terraform-plugin-sdk/v2 to v2.19.0 * Update module github.com/hashicorp/terraform-plugin-framework to v0.10.0 * Fix for hashicorp/terraform-plugin-framework#390 * go mod tidy Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Reference: #81
Reference: #161
Reference: #172
Reference: #365
This introduces a native abstraction over terraform-plugin-go's
tftypes.AttributePath, allowing the framework to own the implementation details and extend the functionality further. Provider developers will be closer to removing a direct dependency on terraform-plugin-go. This is a major breaking change, however it is necessary before 1.0 to prevent compatibility issues in the future and long has been a goal of the framework.This functionality is only intended to replace
tftypes.AttributePathusage and not mess with thetfsdk.Config,tfsdk.Plan, andtfsdk.Statetypetftypes.Valuedata storage fields or their underlying data manipulation logic. This does leave the framework in an awkward half-state until those are further refactored (likely towards nativeattr.Value), but is done to try and reduce the review complexity of this initial migration. Additional followup changes will introduce the concept of path expressions, which will allow provider developers to match against multiple paths or reference parent paths in schema-based plan modifier and validation functionality.To prevent import cycles between
attranddiagpackages due changing theattr.TypeWithValidatetypeValidatemethod signature fromValidate(context.Context, tftypes.Value, *tftypes.AttributePath) diag.DiagnosticstoValidate(context.Context, tftypes.Value, path.Path) diag.Diagnostics, theTypeWithValidationinterface is moved a newxattrpackage underneathattrwith Go and website documentation to direct provider developers to the other package. This will also solve a prior issue with trying to implementTypeWithModifyPlansupport.Naming and location of anything in this initial implementation can be adjusted as necessary.
Provider developers can migrate to the new path handling by replacing:
With the new
github.com/hashicorp/terraform-plugin-framework/pathimport equivalent:Then, if necessary, using the
(Path).At*methods to extend the path definition instead of(*tftypes.AttributePath).With*methods:WithAttributeName()AtName()WithElementKeyInt()AtListIndex()WithElementKeyString()AtMapKey()WithElementKeyValue()AtSetValue()