-
Notifications
You must be signed in to change notification settings - Fork 97
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
attr/xattr: Consider Deprecating tftypes.Value Handling In Preference of attr.Value Handling #589
Comments
This issue is a little more poignant now that we are trying to introduce functions, where function argument data has an argument position instead of a path. Might be a good time to fix this. |
@bendbennett should we create a v2.0.0 issue to remove the deprecated bits? |
v2.0.0 issue to remove the deprecated |
Awesome!! |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Module version
Use-cases
Provider developers should not need to drop down to the
github.com/hashicorp/terraform-plugin-go/tftypes
type system when creating custom types viaattr.Value
with validation. In particular:attr/xattr.TypeWithValidate
Validate(context.Context, tftypes.Value, path.Path) diag.Diagnostics
Attempted Solutions
Proposal
Similar to the framework type system specific
types/basetypes
package interfaces, such asStringTypable
/StringValuable
, introduce validation interfaces that are based on the framework types. Potentially a newtypes/validation
package. Thetypes/basetypes
package cannot be used asdiag.Diagnostics
has a dependency onbasetypes.SetValue
.The existing
attr/xattr.TypeWithValidate
interface and itsValidate
method would be deprecated, instead encouraging the usage of the new interfaces. Theattr/xattr
package cannot be removed until the next major version due to compatibility promises.Proposed
types/validation
package:Note this proposal switches implementation to a request/response pattern similar to other framework handling so that future changes to the requests/responses can be done without updates to the interfaces themselves. Those types can be fairly straightforward for now to match the existing handling:
Inside the framework where the
attr/xattr.TypeWithValidate
interface is referenced will need to be switched to a type switch, e.g.References
attr.Value
s. #172The text was updated successfully, but these errors were encountered: