Besom - a Pulumi SDK for Scala. Also, incidentally, a broom made of twigs tied round a stick. Brooms and besoms are used for protection, to ward off evil spirits, and cleansing of ritual spaces.
The registerResourceOutputs implementation needs to be written. It should be used to correctly handle Stack outputs (exports) and we need to ensure we are able to output them out of pulumi program.
It is recommended to rewrite the supported features into a separate case class, which will be resolved before the Context is created. This can be achieved by making parallel calls to all of the supported feature requests to the backend. Additionally, integrate variables such as PULUMI_DISABLE_RESOURCE_REFERENCES into the same.
A discussion is required regarding the usability of Output for end users, such as handling optionality of Output, dealing with errors in Outputs, and how flatMap from F[_] will work and its correctness.
It is recommended to rewrite the supported features into a separate case class, which will be resolved before the Context is created. This can be achieved by making parallel calls to all of the supported feature requests to the backend. Additionally, integrate variables such as PULUMI_DISABLE_RESOURCE_REFERENCES into the same.
We currently handle the protect flag the same way pulumi-go does and honor only the ResourceOption for a given resource. However, pulumi-java sets protect to true if a resource's parent has it enabled. We need to determine the correct approach.
A CustomTimeouts ResourceOption implementation is missing. A notable part of this task involves converting a scala.concurrent.Duration into a Go duration string.
There's an issue with Decoder[JsValue] - we currently aren't deserializing JSON values. We assumed that they would arrive as strings in protobuf, but they actually arrive as protobuf structs and need to be translated to spray-json AST.
The Remote API logic should be moved out of Context and into a separate entity. This would simplify testing and make Context a thinner entity than it currently is.
URN and ID should be opaque types that are subtypes of String and have validation to obtain them. Currently, we have a stringly typed implementation which leaves room for improvement.
There's an issue with resource propagation in outputEncoder[A]. We are currently passing empty resource sets out of this. It's advisable to check what Go and Java do in this case. This is likely broken.
The current lazy evaluation of Result is causing multiple registrations of the same resource, essentially causing problems with the usage of resources. Outputs that contain resources should be Promise-based to ensure they are effectively memoized.
readOrRegisterResource might not be necessary. It was originally a workaround in pulumi-C# and pulumi-java due to both rehydration and registration hitting the same code path of Resource.constructor. We don't use constructors, we can differentiate between cases and call correct methods on Context.
ResourceOptions.version and pluginDownloadUrl should be Option[String] rather than String. We should not be misusing Scala's type system by passing empty strings.
Work is needed on the Decoder. The 'mapping' feature should be dropped and a way should be found to prevent throwing in implementations (since OutputData doesn't have an error channel). Using 'boundary/break' might be a solution.
In ResourceResolver.resolve, there's a scenario where the id being an empty string is treated differently in pulumi-java. We currently do not account for this, which might be a bug on our side, or a typing issue on pulumi's side.
The current lazy evaluation of Result is causing multiple registrations of the same resource, essentially causing problems with the usage of resources. Outputs that contain resources should be Promise-based to ensure they are effectively memoized.
We pass true to RegisterResourceRequest.acceptSecrets as pulumi-java does, but we need to understand what it does and whether we're using it correctly.
Evaluate whether improvements are needed in handling type casts in Output, as in case out: Output[_] => out.asInstanceOf[Output[A]] // TODO TypeTest?. This might not be necessary as the A type is guaranteed by the extension method being called on Output[A].
For kubernetes args properties (i.e. kind: Pod, version: v1), there should be default values. The const fields in the schema declare which properties have to be passed verbatim. These should be dropped from the apply method argument list and passed as-is to the Args class constructor directly.
The implementation of ResourceTransformations for ResourceOptions needs to be written. We will skip transformations for Args for now as they are arbitrary case classes.
There's a note suggesting implementation of a generic TC[head] typeclass: 'all of these could summon a generic TC[head] typeclass but it's harder so... later?'. This needs to be considered for implementation.
A compatibility matrix needs to be prepared for our libraries, based on the protobuf version on which the language SDK is built, the language SDK version, and the schema version for the provider SDK.
In certain scenarios, where none of the args are required, optional Args should be considered, for example, creating a kubernetes Namespace should be possible with just the name, args should be optional (like passing labels).
There is a need to investigate whether we need a Decoder[Output[A]]. Checking Java and Go implementations might provide some insight into what they do in similar situations.
Currently, our implementation fails if RegisterResourceResponse doesn't contain an object. This might not always be the correct behavior as evidenced by the comment throw new Exception('ONIXPECTED: no object in response') // TODO is this correct?.
Either rename ResourceDecoder or remove the TODO comment associated with it. Current suggestion is to drop the TODO as ResourceDecoder seems appropriate.
The current solution for memoization of resource constructs uses only the name and type as keys. To avoid odd behavior, the solution should also use args and options as keys.