Proper package name for terraform-provider-iterative.

[tasdomas]

Terraform provider modules names are explicitly crafted to prevent imports.

I understand their reasoning (although I still think it's counterproductive), but why should we be doing this?

Does this affect the provider build process? Does this affect how the provider integrates with terraform?

At the moment this only affects us, since upgrading replace dependencies is more of a hassle than I'd like it to be.

Terraform providers were only meant to be consumed through Terraform Core.

Again, how does this impact what we're doing?

Reasons for this choice aren't purely technical, and this topic can easily get into the muddy waters of dogmatic best practices, so bear with me. bear The main purpose of this artificial limitation is preventing providers from exposing a public API that is not stable nor meant to be consumed directly.

That's what internal is for.

I'd suggest to either:

1. Keep using `replace` on the `leo-server` repository and don't modify this module's name. It doesn't make any difference in terms of hackiness and we aren't exposing we don't want to.

2. Extract only the parts we intend to be public API to a new module, e.g. `github.com/iterative/leo`[1](#user-content-fn-1-35e918180fe0d01338df9332d1dbcaa4)

Multiple repos make development slower and introduce additional dependency management steps.

[0x2b3bfa0]

[...] why should we be doing this?

• Does this affect the provider build process?
• Does this affect how the provider integrates with terraform?

This change does not affect the build process and does not affect how the provider integrates with Terraform.

If any, the only valid reason I see to keep the old name is preventing this module from being listed in pkg.go.dev, and overtly imported from other public projects in the same vein as internal directories.

At the moment this only affects us, since upgrading replace dependencies is more of a hassle than I'd like it to be.

I hope to change your mind with https://github.com/iterative/leo-server/pull/27. 😅

Again, how does this impact what we're doing?

Adhering to the purely technical dichotomy of “it compiles or it doesn't” it has absolutely no impact. I'd even argue that if using unreleased changes is a requirement, as hinted in https://github.com/iterative/leo-server/pull/27#pullrequestreview-1204551373, #728 has no [positive] impact whatsoever, because manual updates will still be required.

That's what internal is for.

...ish, yes.

Multiple repos make development slower and introduce additional dependency management steps.

In the age of automation, this doesn't look like an insurmountable issue to me. 🤷🏼‍♂️