rbac_roles is missing from this list, but maybe that was intentional? it definitely seems like the trickiest of these to implement

I'm not sure that this type would really "fit" anywhere in the Terraform provider, even though conceptually it really matches.

The newer "terraform-plugin-framework" style does define local types like this to decode into, but those typically use Terraform "types", and not traditional Go types as is desired here. They look like this:

type UserResourceModel struct {
	ID UUID `tfsdk:"id"`

	Username  types.String `tfsdk:"username"`
	Name      types.String `tfsdk:"name"`
	Email     types.String `tfsdk:"email"`
	Roles     types.Set    `tfsdk:"roles"`      // owner, template-admin, user-admin, auditor (member is implicit)
	LoginType types.String `tfsdk:"login_type"` // none, password, github, oidc
	Password  types.String `tfsdk:"password"`   // only when login_type is password
	Suspended types.Bool   `tfsdk:"suspended"`
}

I could plan around with this, and maybe using the Terraform types would be fine? but it's also a little weird because we'd be adding them to that package without it actually being intended for use anywhere in it.

It also gets complicated because we'll only be embedding one version of the evaluation engine in the product, but customers could be using any number of versions of the Terraform provider in their templates. Do we think that poses any risk? Might we eventually need separate types for separate provider versions, especially if we ever bump the provider to v2?

rbac_roles is missing from this list, but maybe that was intentional? it definitely seems like the trickiest of these to implement

I do think roles awareness is crucial for customer value here. Does custom roles also exponentially increase complexity? 👀

Do we think that poses any risk? Might we eventually need separate types for separate provider versions, especially if we ever bump the provider to v2?

This is a really good point. How does compatibility work with preview vs provider versions, and can we promise backward compatibility.

rbac_roles is missing from this list, but maybe that was intentional? it definitely seems like the trickiest of these to implement

We should include it. It is new, I just missed it.

I'm not sure that this type would really "fit" anywhere in the Terraform provider, even though conceptually it really matches.

@aslilac if it does not make sense, do not worry about it. Just trying to share code where possible.

It also gets complicated because we'll only be embedding one version of the evaluation engine in the product, but customers could be using any number of versions of the Terraform provider in their templates. Do we think that poses any risk? Might we eventually need separate types for separate provider versions, especially if we ever bump the provider to v2?

We can deal with that bridge when we get to it. We'd have to take a look at the provider version and switch the code behavior.