<@U048XG9UDS8> PR 964 <https://github.com/pulumi/p...
# package-authoring
b
@narrow-match-14013 PR 964 https://github.com/pulumi/pulumi-terraform-bridge/pull/964 introduced this breaking change and there's documentation how to change the code as well. But be aware of issue https://github.com/pulumi/pulumi-terraform-bridge/issues/1019 😉
n
Thanks! I got it working now. But i'm wondering what is the purpose of the
//go:embed
then? If
tfgen
creates the file, and then the bridge imports what it creates, why is it embedded in tfgen?
b
@narrow-match-14013 The problem with the current approach is described in issue 1019. Because metadata.json is embedded now in resources.go instead of the main.go of the provider, tfgen can't be compiled because it relies on resources.go but, especially for the initial run of tfgen, when there's no metadata.json at all, building tfgen itself fails. As said this is tracked in 1019. As long as this isn't the case you must ensure that at least an empty metadata.json is present to have tfgen compiled successfully. My template takes this into account (aside some other things) and makes wrapping a Terraform provider really easy. https://github.com/tmeckel/pulumi-tf-provider-cookiecutter
n
OK I think I understand now. So in
tfgen
I can actually just pass an empty
make([]byte, 0)
into the
tfbridge.NewProviderMetadata
, but then in the
resource
binary I can use the embed and pass that in, and it seems to work
the "problem" is that the same
ProviderInfo
is used in both
tfgen
and
resource
, when only the latter actually needs
bridge-metadata.json
to exist