This is particularly frustrating as I've spent the last year writing many thousands of lines of CDKTF Python. HCL just does not have the modularity and expressiveness that Python, or other languages CDKTF supports. I guess I'll spend another year migrating to Pulumi now..
The lack of expressiveness of HCL is the point and what makes it so good
The future of Terraform CDK
51–60 of 140 posts
Re: The future of Terraform CDK
#52Re: The future of Terraform CDK
#53Earlier quoted context omitted.
Does it do ephemeral values yet?
Yep, as of yesterday’s 1.11 release it’s supported! That also includes a new “enabled” meta argument, so you don’t have to hack around conditional resources with count = 0. [0]: https://opentofu.org/blog/opentofu-1-11-0/ Disclaimer: affiliated with the project
Re: The future of Terraform CDK
#54Re: The future of Terraform CDK
#55As an alternative is anyone considering https://sst.dev/ (which uses Pulumi under the hood)? We use it at work and I’ve been quite happy with it
Re: The future of Terraform CDK
#56Earlier quoted context omitted.
The lack of expressiveness of HCL is the point and what makes it so good
Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.
Re: The future of Terraform CDK
#57Earlier quoted context omitted.
How do you migrate from count/for_each to `enabled` ?
You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply. It's pretty seamless.
Re: The future of Terraform CDK
#58Earlier quoted context omitted.
I went with CDK, I'm locked into AWS already and it means my major dependency for IaC is my cloud vendor and not a third party. If I really need to migrate off of AWS at some point I'll throw an LLM at it.
Exactly. It's just so much cleaner to do it in the Cloud provider's native tooling. The impedance mismatch from Cloud-agnostic abstractions always just makes thing shitty enough that in the long run you spend more time dealing with weird edge cases. Besides, actual full-scale Cloud migrations are exceedingly rare.
Re: The future of Terraform CDK
#59Re: The future of Terraform CDK
#60It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.
I was thinking the same thing about the "an IBM company". My guess is that it's a lazy find/replace.