Attempt to port a serverless component to this library #17
Conversation
|
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
|
cc @iwahbe @harribo11 for thoughts on questions/notes above. |
|
|
Concur with Ian on points 1 and 2. Will our token system work across all providers? For example the docker provider has type tokens formatted |
lukehoban
force-pushed
the
lukehoban/serverless
branch
from
63f4ae1 to
e88f8b7
Compare
|
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
|
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
| component := &Service{} | ||
| // What about opts? | ||
| err := ctx.RegisterComponentResource("serverless:index:Service", name, component) | ||
| if err != nil { | ||
| return err | ||
| } | ||
|
|
There was a problem hiding this comment.
| component := &Service{} | |
| // What about opts? | |
| err := ctx.RegisterComponentResource("serverless:index:Service", name, component) | |
| if err != nil { | |
| return err | |
| } |
s is the component that you are registering here. You don't need to create a new component or register it. We don't expose Options, since they should all be inherited by parenting s. Let me know if you can think of a reason we need to expose Options.
| component.Url = out.ApplyT(func(v interface{}) *string { | ||
| return v.(*string) | ||
| }).(pulumi.StringPtrOutput) | ||
|
|
||
| if err := ctx.RegisterResourceOutputs(component, pulumi.Map{ | ||
| "url": component.Url, | ||
| }); err != nil { | ||
| return err | ||
| } |
There was a problem hiding this comment.
| component.Url = out.ApplyT(func(v interface{}) *string { | |
| return v.(*string) | |
| }).(pulumi.StringPtrOutput) | |
| if err := ctx.RegisterResourceOutputs(component, pulumi.Map{ | |
| "url": component.Url, | |
| }); err != nil { | |
| return err | |
| } | |
| s.Url = out.ApplyT(func(v interface{}) *string { | |
| return v.(*string) | |
| }).(pulumi.StringPtrOutput) |
|
Closing, since this is out of date. |
This is the beginnings of an attempt to use this library to use this library to port a slightly non-trivial component. A few questions/issues that came up - curious if there are thoughts on these, or features that need to be added to support these:
pulumiSDK types are allowed. How are nested types supported? I see in the provider implementations that plain types are used, so these aren't needed. But in the components, they seem to (rightly?) expect to work with inputs/outputs that are Inputs/Outputs. But then how do I use nested types within this?types.gofile used in https://github.com/pulumi/pulumi-package-serverless/ (which I am porting from). Not everything there is strictly necessary - but a lot of it seems to be. Is there a better way to author this with this model? Note that in the original variant of this, I actually wrote schema first, then generated SDK, then stole the SDK types back into the implementation to use for the implementation of the Construct. Convoluted for sure - but with this amount of nested types - authoring in schema was actually quite a lot simpler than in Go types. Can this be easier with the higher level framework here?main_test.gothat runs ProgramTest with a YAML program (so that SDK isn't needed for inner loop testing)??Currently this is blocked on (2) above - resulting in: