New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Eject function to use from "pulumi convert" #630
Conversation
@@ -74,7 +74,7 @@ func TestConvert(t *testing.T) { | |||
import * as pulumi from "@pulumi/pulumi"; | |||
|
|||
const config = new pulumi.Config(); | |||
const regionNumber = config.get("regionNumber") || { | |||
const regionNumber = config.getObject("regionNumber") || { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this must be because the tf11 code generator used get, but tf12 uses getObject. It's probably a safe change but I haven't dug into or thought too hard about it.
Diff for pulumi-random with merge commit 7647572 |
Diff for pulumi-azuread with merge commit 7647572 |
Diff for pulumi-gcp with merge commit 7647572 |
Diff for pulumi-azure with merge commit 7647572 |
Diff for pulumi-aws with merge commit 7647572 |
Diff for pulumi-random with merge commit a500512 |
Diff for pulumi-azuread with merge commit a500512 |
Diff for pulumi-gcp with merge commit a500512 |
Diff for pulumi-azure with merge commit a500512 |
Diff for pulumi-aws with merge commit a500512 |
Pondering on this idea some more, I wonder if using pulumi to host tfconvert is the right order to do things. I wonder if instead we should add something to the automation api to flip this around such that tfconvert uses the automation api to get an engine interface to make plugin schema and codegen requests from. That still solves the coupling issue (codegen and schema fetching done via a stable grpc interface, and plugin loading and execution totally internal to the engine) but it's less flipping around the execution order of things, and also might be what we need for the yaml-lsp as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like a refactor like this should try to preserve existing tests, but I leave this one up to your discretion.
Your idea of using the automation API to have tf2pulumi
invoke the engine to get access to RPC is interesting. I think in this case, it makes sense to launch tf2pulumi
via pulumi convert
, just because I think we want pulumi convert --language lang --out out
to be as universal as possible.
The LSP sever will need a different mechanism, your suggestion makes a lot of sense there.
I'm hoping to get rid of all the language specific tests over the next few weeks anyway, so I'll commit this with the intention we're going to loop back heavily over testing soon. |
No description provided.