Consider Refactoring tfsdk Schema/Attribute/Block Logic into internal Package(s)

[bflad]

Module version

v0.8.0

Use-cases

While working through some of the framework server refactoring as part of #215, it was necessary to extract some of the tfsdk.Attribute, tfsdk.Block, and tfsdk.Schema unexported methods into temporary functions within the internal/fwserver package so they did not become part of the public tfsdk APIs. For example, SchemaValidate() and SchemaModifyPlan(). This highlighted that a larger portion of the schema handling would benefit as being in internal packages and colocated again, rather than splitting the logic across packages, while still exporting provider developer functionality only as necessary in tfsdk or some other "public" package.

Proposal

To be written up, but a current thought is that there should be an internal/schema or similar package which contains the full framework schema/attribute/block handling, while tfsdk or another package merely exposes anything that should be in the public API.

References

• #215

[bflad]

This type of change is essentially required for #132, which provider developers are asking to be implemented.

[bflad]

This issue should be closable early in the v0.12.0 development cycle once we've released deprecations of some existing functionality that shouldn't affect most provider developers.

[bflad]

This internal package refactoring was completed previously. Other issues can be used to track additional efforts.

[github-actions[bot]]

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. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.