Consider generating encoders for output args

[pawelprazak]

The following use case:

 val nginxService = Service(
    "nginx",
    ServiceArgs(
      spec = ServiceSpecArgs(
        selector = labels,
        `type` = k8s.core.v1.enums.ServiceSpecType.LoadBalancer,
        ports = List(...)
      ),
      metadata = ObjectMetaArgs(...)
    )
  )

  Stack.exports(
    nginxUrl = nginxService.status.loadBalancer
  )

Requires the following workaround:

  given besom.types.Encoder[besom.api.kubernetes.core.v1.outputs.PortStatus] = besom.internal.Encoder.derived
  given besom.types.Encoder[besom.api.kubernetes.core.v1.outputs.LoadBalancerIngress] = besom.internal.Encoder.derived
  given besom.types.Encoder[besom.api.kubernetes.core.v1.outputs.LoadBalancerStatus] = besom.internal.Encoder.derived

To get this output from pulumi:

...
Outputs:
    nginxUrl           : {
        ingress: [
            [0]: {
                hostname: "localhost"
            }
        ]
    }
...

[lbialy]

Don't we generate that already? There are two options if we don't: a) add that in codegen and look how much large packages swell, I guess it might be a non trivial amount

b) provide an inline given for Encoders in exports that reach user's code and therefore allow user to derive Encoder on demand

Option A has the benefit of us knowing on package publishing level that something is no yes with caveat of swollen packages.

Option B has the benefit of smaller package size with caveat of missing given errors exposed to the user if something can't be derived.

There's a middle ground option of verifying that we can derive all Encoders for all output args in some kind of post-build test stage (would require two stage generation in codegen, one package would be the core package that we publish, second would depend on first and just verify that we can derive Encoders for all output args so compile failure would prevent publish of first package).

[pawelprazak]

We have encoders for input args but not for output args, only decoder there.

This works OOTB in other implementations, so my expectation, if I was a use, was to be of parity.

I agree this adds code to providers and technical limitations of that needs to be taken into account.