Implement GetRequiredPackages for Java
#1535
Conversation
lunaris
force-pushed
the
wjones/get-required-packages
branch
from
c6c1fe5 to
3459c61
Compare
| ctx context.Context, | ||
| req *pulumirpc.GetRequiredPluginsRequest, | ||
| ) (*pulumirpc.GetRequiredPluginsResponse, error) { | ||
| logging.V(5).Infof("GetRequiredPlugins: program=%v", req.GetProgram()) //nolint:staticcheck |
There was a problem hiding this comment.
Was removing this log intentional? It still seems useful to know when GetRequirePackages is called (though we are pretty inconsistent with logging overall)
There was a problem hiding this comment.
It was -- I checked the PR in pulumi/pulumi that added GetRequiredPackages for Go, NodeJS and Python, and it seemed like we weren't doing any logging there really for those calls, so I figured I'd remove it. But I can add something back before I merge -- agree it doesn't hurt 👍
There was a problem hiding this comment.
Ah fair enough. I didn't double check for those. Might be worth adding them there for consistency ;)
| context.Context, | ||
| *pulumirpc.GetRequiredPluginsRequest, | ||
| ) (*pulumirpc.GetRequiredPluginsResponse, error) { | ||
| return nil, status.Errorf(codes.Unimplemented, "method GetRequiredPlugins not implemented") |
There was a problem hiding this comment.
I was wondering if we still need to implement this, so it works with an older engine. But language runtime plugins are always bundled, so we know we'll always call GetRequiredPackages first anyway. Good.
There was a problem hiding this comment.
On both your comments, I've tried to match what was done for Go, NodeJS and Python -- it seems like we did the add/remove simultaneously for them and as you say, this is bundled so I think it's OK?
There was a problem hiding this comment.
Yeah, I think this is fine, I just stumbled over it, so wanted to double check my thought process :)
lunaris
force-pushed
the
wjones/get-required-packages
branch
3 times, most recently
from
baddcfd to
e8fc393
Compare
As part of a Pulumi deployment, the Pulumi engine will ask the language host running the program for the set of plugins required to run that program successfully by making a `GetRequiredPlugins` gRPC call. For instance, if one has a TypeScript program whose `index.ts` `import`s `@pulumi/aws`, the NodeJS language host will find the `@pulumi/aws` package and report that the `aws` resource plugin is required. This enables features such as pre-emptively downloading a plugin ahead of time, as opposed to waiting for the first resource registration against that plugin. With the introduction of parameterized providers, `GetRequiredPlugins` falls a little short -- parameterization means that it is no longer necessarily the case that a package named `x` is provided by a plugin of the same name. For instance, with a dynamically bridged Terraform provider X, the provider name will be X, but the plugin name will be e.g. `pulumi-terraform-provider`. In pulumi/pulumi#17894, `GetRequiredPackages` was added to the language host interface to provide the additional context of a plugin's parameterization, and is now used if present instead of `GetRequiredPlugins`. This change implements `GetRequiredPackages` for Java as follows: * Presently, `GetRequiredPlugins` is implemented by running a small Java program (located in the internal `bootstrap` package of the core SDK) that walks its class path looking for `pulumi-plugin.json` files. This code is extended to parse `parameterization` blocks from those JSON files, as we do in other languages using this mechanism. * When we generate SDKs, we generate Gradle build files which generate `pulumi-plugin.json` files as part of the build process. We extend the `build.gradle` template used when generating SDK build files so that it emits `parameterization` blocks appropriately. As part of this, we also clean up the emission of package names and versions. * We now have enough to run and pass the `l2-parameterized-resource` conformance test, which in theory confirms that all of this works, so we include that as part of this work. * We remove the now-deprecated `GetRequiredPlugins` implementation. Fixes #1510
lunaris
force-pushed
the
wjones/get-required-packages
branch
from
e8fc393 to
e94090c
Compare
This conformance test can be enabled with the implementation of `GetRequiredPackages` from #1535.
This conformance test can be enabled now with the implementation of `GetRequiredPackages` from #1535.
As part of a Pulumi deployment, the Pulumi engine will ask the language host running the program for the set of plugins required to run that program successfully by making a
GetRequiredPluginsgRPC call. For instance, if one has a TypeScript program whoseindex.tsimports@pulumi/aws, the NodeJS language host will find the@pulumi/awspackage and report that theawsresource plugin is required. This enables features such as pre-emptively downloading a plugin ahead of time, as opposed to waiting for the first resource registration against that plugin.With the introduction of parameterized providers,
GetRequiredPluginsfalls a little short -- parameterization means that it is no longer necessarily the case that a package namedxis provided by a plugin of the same name. For instance, with a dynamically bridged Terraform provider X, the provider name will be X, but the plugin name will be e.g.pulumi-terraform-provider. In pulumi/pulumi#17894,GetRequiredPackageswas added to the language host interface to provide the additional context of a plugin's parameterization, and is now used if present instead ofGetRequiredPlugins. This change implementsGetRequiredPackagesfor Java as follows:GetRequiredPluginsis implemented by running a small Java program (located in the internalbootstrappackage of the core SDK) that walks its class path looking forpulumi-plugin.jsonfiles. This code is extended to parseparameterizationblocks from those JSON files, as we do in other languages using this mechanism.pulumi-plugin.jsonfiles as part of the build process. We extend thebuild.gradletemplate used when generating SDK build files so that it emitsparameterizationblocks appropriately. As part of this, we also clean up the emission of package names and versions.l2-parameterized-resourceconformance test, which in theory confirms that all of this works, so we include that as part of this work.GetRequiredPluginsimplementation.Fixes #1510