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.
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
Create diag package and switch all applicable []tfprotov6.Diagnostic usage #110
Create diag package and switch all applicable []tfprotov6.Diagnostic usage #110
Changes from all commits
dcda800
27a1779
6ba3d30
1764adb
6b36115
fc3a0cf
3e2bd75
8237b08
8bd19e3
0e1a0c0
9517ae4
c6d33e7
473b6e1
c033750
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
two things:
diag
package or benefit from being a method on theDiagnostics
type. Is there a reason we shouldn't just make it a function intfsdk
?Tfprotov6
in this may be unnecessarily verbose.ToProto6Diagnostics
is probably sufficient; we know which protocol we're talking about, and we're unlikely to be talking about any other protocol's diagnostics except Terraform's.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.
It does keep the diagnostics implementation altogether.
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.
Hm. Is that worth having an exported method we don't want people to call? 🤔 (I don't know the answer, I'm wondering out loud.)
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.
Another option here would be to move that exported function into a separate
internal
package, maybe along the lines ofdiag/internal/convert
. I'd be more apt to do this so at least the code is tangential the other diagnostics code. I'd be worried about import cycles if we tried to setup something more generic likeinternal/toproto6
.@kmoe do you have any opinions?
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'd still prefer this to be unexported as we don't expect provider developers to use it, and I'm worried about what they'll do with this unintended compatibility interface, but I'm not gonna hold this up over it.