Closed roni-frantchi closed 4 years ago
@roni-frantchi Thank you for opening the PR.
Historically, I wrote the tfschema before the official terraform providers schema -json
command was implemented. I'm maintaining this project for myself as a human-friendly CLI tool for now. So I'll pay attention to breaking changes for CLI, but cannot guarantee its stability as a Go library. So if you want to parse schema from program in a stable way, I first recommend to parse the output of terraform providers schema -json
command.
I'm not intended to discourage you (if you feel so, I'm sorry), I'm just curious about why do you use the tfschema as a Go library not directly depends on terraform. Could you share your use-case if possible? If it makes sense, I'll move on the code review.
Thanks!
Hey @minamijoyo thanks!
I think I prefer having the abstraction tfschema
offers in dealing with, say multiple Terraform versions - for instance the work you've recently done to get it to work with Terraform 0.13.
@roni-frantchi Supporting multiple terraform versions is complicated and you'd be implementing the almost same logic without tfschema. I understood using tfschema as a library may be reasonable for such case.
For implementation, I think #25 is more on right direction to meet your needs. Because Terraform v0.13 uses a hierarchical directory structure to support third-party provider namespaces. This means we don't know exactly plugin directory without peeking a lock file. So setting a root module directory instead of a plugin directory is a natural way to implement it.
When using
tfschema
to be used as a library rather than a CLI tool, it is useful to allow the plugin directory to be specified to allow other tools which enable to target a Terraform working directory, to build upontfschema
.