Are there any plans for a conditional way to enable/disable modules that doesn't use "count"?

For example:

  # current method
  module "foo" {
    count = var.enable_foo ? 1 : 0
  }

  # better?
  module "bar" {
    enabled = var.enable_bar
  }

Preconditions and postconditions fail the apply run if their condition doesn't validate, so those can't be used.

I'd also really like to be able to say in an output block, "this value doesn't have to exist, only display it if its parent module is enabled", again without the "count" attribute.

The relevant issue[0] is currently the 7th top-voted[1] feature request, so it's definitely high on our radar. Please upvote it as well, if it's important to you!

There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works.

[0]: https://github.com/opentofu/opentofu/issues/1306

[1]: https://github.com/opentofu/opentofu/issues/1496

Use CDKTF.

All of these "how can I do X in HCL" just go away.

I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1].

This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations.

[1]: https://developer.hashicorp.com/terraform/cdktf/concepts/fun...

Once in a while, I forget to use Fn when I should.

But I'll take that annoyance anyday over the absolute pain of HCL.

I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)

I suspect Pulumi is easy to extend because most of the API is basically a state-preserving, idempotent wrapper around existing APIs. When I was messing with it on GCP, their API almost always used the exact same objects the GCP API accepted. I could actually use the GCP docs to create the objects (there are big upsides and downsides to this).

Are there any incompatibilities cropping up between terraform and opentofu? I believe we're on terraform 1.7.5, I'm not sold on migrating yet but would like to keep the option open, especially if something like delaying an upgrade would help not have future backwards incompatible things to fix.

I understand why people were upset about licensing changes but I was not one of them who were particularly bothered. Why should I switch?

> Are there any incompatibilities cropping up between terraform and opentofu?

OpenTofu is indeed a hard fork. When doing similar features (like provider-defined functions) we try to stay compatible where it makes sense, but there's often some differences (like our more extended capabilities of provider-defined functions[0]) and also new features in Terraform that we're not introducing - and vice versa.

You can check for known incompatibilities in our migration guides[1], based on your Terraform version. In practice, the longer you wait, the more the projects will diverge, so if you still want to "wait and see" I would suggest settling on your current Terraform version for now - otherwise, the migration will just be more work for you later.

Regarding the reasons for switching, I'd say features and community-first process. We're striving to be very community driven in what work we're prioritizing[2] and have received a lot of positive feedback over that from our users.

Some companies we've spoken to see adopting the open-source community-driven project as a way to reduce risk long-term. It's also a way to keep your options open if you're in the market for commercial Terraform/OpenTofu management systems.

[0]: https://github.com/opentofu/terraform-provider-go

[1]: https://opentofu.org/docs/intro/migration/

[2]: https://github.com/opentofu/opentofu/issues/1496

I'm really excited to see the end-to-end state encryption. I've always thought it was bizarre that Hashicorp didn't prioritize this.

Could it be because it weakens the business case for using their SAAS?

Possibly, but we are paying enterprise customers (but not using HCP) and this still isn't possible. Seems like an obvious thing they could have at least offered to vault enterprise or TF enterprise customers years ago.

My guess is internal politics in the development team(s) rather than commercial reasons.

The trend will continue. A company will be crazy to trust that IBM would give them fair-priced high quality support.

Do you appreciate the irony of that comment on a post about Oracle adopting OpenTofu?

I'm sure Oracle doesn't want to be gouged by their vendors any more than the rest of us do. They probably don't buy Oracle either.

Yep. Funny.

In this case Oracle is the user, not the vendor.