The first solution is intentionally narrow in scope, but the potential use cases are huge. To do things like pinning a provider across many stacks I've been using Terramate to autogenerate all my Tofu code. Being able to define it as a variable will really simplify things.

Also, I'm on Soren's Terramate beta cloud product and I'm happy to say it works just fine with OpenTofu

First of all I'd like to emphasize on the fact that the HC acquisition by IBM has not been finalized yet!

To answer the question if it is safe to use OpenTofu. TLDR; "yes, but it depends on your business case" Long Version: If there's no urgent reason for you to switch (in a sense of features that exist in OpenTofu only vs you are impacted by the license change) you probably don't need to switch / make a fast move. Both projects are already diverging and both the OpenTofu as well as HashiCorps team have accelerated adding new features.

Yeah, the OpenTofu contributors have signaled that they are happy to merge the code bases as long as the end result is something that will be owned by the CNCF. IMO, that would be what's best for everyone.

That'd be my preferred scenario too. Merging both projects under the umbrella of the Linux Foundation to guarantee a decentralized, independent and proven governance model.

Other than that I am currently not aware of any talks or legal issues between the both

IMO, there were some comically bad takes on the letter early on that started getting traction on social media, and that muddied the waters considerably.

@Troy Knapp re your issue in https://github.com/opentofu/opentofu/issues/1760 Currently, you can work around this by using

null_resources

to delay the execution of data sources to the apply phase.

data "aws_subnet" "subnet" {
  filter {
    name = "tag:Name"
    values = [
      "us-east-1a",
    ]
  }

  depends_on = [
    null_resource.initial_deployment_trigger,
  ]
}

resource "null_resource" "initial_deployment_trigger" {}

I have an ulterior motive for this PR (besides the fact that its annoyed me for years) The real reason I created this issue is that I've got a go script that I'm testing out that • allows you to annotate an output like this:

# Output the path to the local file
# @public
output "local_file_path" {
  description = "Filename of the local file"
  value       = local_file.my_local_file.filename
}

• it pulls the provider schema • looks up the corresponding data source • finds the required attributes for said source • pulls the attributes from the state • creates a new module with data sources, providers, and outputs that can be consumed by other stacks The problem is that when you include a module like the one above, it'll only work if the apply in the parent has already happened. I want to be able to validate and not throw an error. So the problem here isn't delaying it until the apply phase (which your solution definitely fixes) but not throwing an error when a parent stack's resource isn't created yet and I want to generate a plan or something. I ran into the issue I described in the PR a lot when I was really fresh in IAC and trying to migrate from clickops. Things in the cloud were applied inconsistently in different environments. I tried to use as much of the same code everywhere as possible, but I was constantly trying to import resource after resource. So having some way to normalize everything and get a good starting point would have been really helpful.