search

VirtusLab / besom

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.
https://virtuslab.github.io/besom/
Apache License 2.0
122 stars 7 forks source link

Provide `pulumiResourceName` and `pulumiProject`, `pulumiOrganization`, `pulumiStack` #295

Closed dubinsky closed 10 months ago

dubinsky commented 10 months ago

In Pulumi, name given to a resource at construction time can be recovered by calling pulumiResourceName method on the com.pulumi.resources.Resource. What is the Besom way of doing this?

Thanks!

lbialy commented 10 months ago

Hi!

We don't really have pulumiResourceName as such (maybe we should?) but it's still possible to access the resource's logical name via URN. Each and every resource has to have a urn field of type Output[URN] where URN is an opaque type with several extensions allowing access to it's parts (one of which is a logical resource name!). Therefore:

    val redisNamespace = Namespace(s"redis-cluster-namespace-$name")

    redisNamespace.urn.map(_.resourceName): Output[String]

I think we can add some extension syntaxes for all resources to just have this and that wouldn't be a breaking change. Adding a field to each generated resource to hold on to the logical name would be a breaking change but maybe we should make it.

Do you feel that getting that name in Output[String] is inconvenient?

dubinsky commented 10 months ago

I think we can add some extension syntaxes for all resources to just have this and that wouldn't be a breaking change. Adding a field to each generated resource to hold on to the logical name would be a breaking change but maybe we should make it.

Everything works great even without adding anything. Thanks!

Do you feel that getting that name in Output[String] is inconvenient?

It's perfectly fine! (And will only get better with https://github.com/VirtusLab/besom/issues/291...)

Thank you!!

pawelprazak commented 10 months ago

@dubinsky I'm glad you're having fun with Besom, please let us know if any other issue comes to mind :)

@lbialy maybe we could improve the API a bit and it is still less characters than pulumiResourceName ;) redisNamespace.urn.map(_.resourceName) -> redisNamespace.urn.resourceName

dubinsky commented 10 months ago

I'm glad you're having fun with Besom, please let us know if any other issue comes to mind :)

I am having lots of fun! Thank you!!

1) I need things like OrganizationsFunctions.getOrganization(GetOrganizationArgs) (GCP), but I see that they are in the next release. Thanks! When is the next release planned? 2) What are the plans for tracking changes to the providers? I am using org.virtuslab:besom-gcp_3:6.66.0-core.0.1.0, and while 0.1.0 is the latest released version of Besom, 6.66.0 is not the latest released version of GCP ;) 3) Is GitHub Issues the way to contact you with questions or will there be something more conversational (GitHub Discussions? Something else?)

Thanks!

dubinsky commented 10 months ago

On this specific issue:

  1. I agree that writing resource.urn.resourceName instead of resporce.urn.map(_.resourceName) is cleaner and more in the "lifted" style of Besom... but how far should this go? Lift all the URN components? Everything?
  2. I think that retrieval of the resource name (and other URN components) should be documented. https://virtuslab.github.io/besom/docs/constructors? https://virtuslab.github.io/besom/docs/interpolator?
lbialy commented 10 months ago
  1. Paweł has provided docs for that today but I stopped him because I would prefer that we document the extensions once we make this change.
  2. Fun fact is - we have started with a prototype created by @Prolativ in which everything was able to be lifted via refinements and macro-driven Selectable Output monad. Given the need for refinement types support in IDE to support this feature we've went with simpler and well supported design based on code-generated extensions. Now I personally think that said prototype is the way to go in ergonomy of all monadic interfaces but it's not yet ready for prime time for sure (compilation times would probably explode as well).

About how far we should go with lifting of resource properties that are in the urn - I think there's no reason to define:

extension (outputOfRes: Output[Resource])
  def pulumiResourceName: Output[String] =
    outputOfRes.flatMap(_.urn).map(_.resourceName)

The only issue I have with adding more of the props this way is that there's a slight possibility of conflicts (but probably not if we prefix those accessors with "pulumi"!). Going via outputResource.urn.resourceName feels a bit esoteric for me - user has to know about URNs and while they are quite basic and important concept I don't feel they are as in-the-face as resources and outputs. I'd prefer outputResource.pulumiResourceName personally as in other sdks.

Tell me what you think!

dubinsky commented 10 months ago

Now I personally think that said prototype is the way to go in ergonomy of all monadic interfaces but it's not yet ready for prime time for sure (compilation times would probably explode as well).

Hope to see it some day!

Given the need for refinement types support in IDE to support this feature we've went with simpler and well supported design based on code-generated extensions.

My IDE (Idea) does not let me click through to the definitions of the extension method like urn...

Going via outputResource.urn.resourceName feels a bit esoteric for me - user has to know about URNs and while they are quite basic and important concept I don't feel they are as in-the-face as resources and outputs. I'd prefer outputResource.pulumiResourceName personally as in other sdks.

I completely agree, outputResource.pulumiResourceName is better than outputResource.urn.resourceName.

I personally do not need access to the other components of the urn ;)

pawelprazak commented 10 months ago

I'm glad you're having fun with Besom, please let us know if any other issue comes to mind :)

I am having lots of fun! Thank you!!

  1. I need things like OrganizationsFunctions.getOrganization(GetOrganizationArgs) (GCP), but I see that they are in the next release. Thanks! When is the next release planned?
  2. What are the plans for tracking changes to the providers? I am using org.virtuslab:besom-gcp_3:6.66.0-core.0.1.0, and while 0.1.0 is the latest released version of Besom, 6.66.0 is not the latest released version of GCP ;)
  3. Is GitHub Issues the way to contact you with questions or will there be something more conversational (GitHub Discussions? Something else?)

Thanks!

  1. yes, top-level functions have codegen part done (the provider SDK code generation), we're working on the core part of the plumbing from the function all the way down to gRPC call to the Pulumi engine
  2. the long term plan would be to automate the releases, so we re-release providers daily if new version is detected- thats the goal, right now we prioritize feature parity with upstream and stabilization, but there is a semi-automatic script for the release, so every time we release, we release the providers with the newest versions; as to the mentioned GCP, I've tested the 7.0.0 and it builds
  3. Personally I'm happy answering GH question issues, but we should probably enable GH discussions, @lbialy WDYT?
lbialy commented 10 months ago

Is there any benefit in conversations over question issues? I mean, beside separation of questions and bug reports? I'm OK with that but for issues I get emails and can just respond in Gmail. Dunno what the flow with convos would be. I have a gh app, maybe it's fine.

On Wed 15. Nov 2023 at 09:41, Paweł Prażak @.***> wrote:

I'm glad you're having fun with Besom, please let us know if any other issue comes to mind :)

I am having lots of fun! Thank you!!

  1. I need things like OrganizationsFunctions.getOrganization(GetOrganizationArgs) (GCP), but I see that they are in the next release. Thanks! When is the next release planned?
  2. What are the plans for tracking changes to the providers? I am using org.virtuslab:besom-gcp_3:6.66.0-core.0.1.0, and while 0.1.0 is the latest released version of Besom, 6.66.0 is not the latest released version of GCP ;)
  3. Is GitHub Issues the way to contact you with questions or will there be something more conversational (GitHub Discussions? Something else?)

Thanks!

  1. yes, top-level functions have codegen part done (the provider SDK code generation), we're working on the core part of the plumbing from the function all the way down to gRPC call to the Pulumi engine
  2. the long term plan would be to automate the releases, so we re-release providers daily if new version is detected- thats the goal, right now we prioritize feature parity with upstream and stabilization, but there is a semi-automatic script for the release, so every time we release, we release the providers with the newest versions; as to the mentioned GCP, I've tested the 7.0.0 and it builds
  3. Personally I'm happy answering GH question issues, but we should probably enable GH discussions, @lbialy https://github.com/lbialy WDYT?

— Reply to this email directly, view it on GitHub https://github.com/VirtusLab/besom/issues/295#issuecomment-1812023258, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBVNUSH6EDN5TWISSC2J23YER54LAVCNFSM6AAAAAA7KCXPMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGAZDGMRVHA . You are receiving this because you were mentioned.Message ID: @.***>

pawelprazak commented 10 months ago

Now I personally think that said prototype is the way to go in ergonomy of all monadic interfaces but it's not yet ready for prime time for sure (compilation times would probably explode as well).

Hope to see it some day!

Given the need for refinement types support in IDE to support this feature we've went with simpler and well supported design based on code-generated extensions.

My IDE (Idea) does not let me click through to the definitions of the extension method like urn...

Going via outputResource.urn.resourceName feels a bit esoteric for me - user has to know about URNs and while they are quite basic and important concept I don't feel they are as in-the-face as resources and outputs. I'd prefer outputResource.pulumiResourceName personally as in other sdks.

I completely agree, outputResource.pulumiResourceName is better than outputResource.urn.resourceName.

I personally do not need access to the other components of the urn ;)

I agree, outputResource.pulumiResourceName is more discoverable, and the prefix avoids collisions.

In spirit of that, we'd also need pulumiProject, pulumiOrganization, pulumiStack on the Context, as they are exposed in every SDK and tend to be useful in my experience.

lbialy commented 10 months ago

Can you make an issue for that and mark for 0.2.0? All of these small things are 10m tasks I just need to find time to go through in one go.

On Wed 15. Nov 2023 at 10:30, Paweł Prażak @.***> wrote:

Now I personally think that said prototype is the way to go in ergonomy of all monadic interfaces but it's not yet ready for prime time for sure (compilation times would probably explode as well).

Hope to see it some day!

Given the need for refinement types support in IDE to support this feature we've went with simpler and well supported design based on code-generated extensions.

My IDE (Idea) does not let me click through to the definitions of the extension method like urn...

Going via outputResource.urn.resourceName feels a bit esoteric for me - user has to know about URNs and while they are quite basic and important concept I don't feel they are as in-the-face as resources and outputs. I'd prefer outputResource.pulumiResourceName personally as in other sdks.

I completely agree, outputResource.pulumiResourceName is better than outputResource.urn.resourceName.

I personally do not need access to the other components of the urn ;)

I agree, outputResource.pulumiResourceName is more discoverable, and the prefix avoids collisions.

In spirit of that, we'd also need pulumiProject, pulumiOrganization, pulumiStack, as they are exposed in every SDK and tend to be useful in my experience.

— Reply to this email directly, view it on GitHub https://github.com/VirtusLab/besom/issues/295#issuecomment-1812094452, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBVNUWYIS46BBODX7ZV5WLYESDR5AVCNFSM6AAAAAA7KCXPMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGA4TINBVGI . You are receiving this because you were mentioned.Message ID: @.***>

dubinsky commented 10 months ago

@pawelprazak

Personally I'm happy answering GH question issues, but we should probably enable GH discussions

@lbialy

Is there any benefit in conversations over question issues? I mean, beside separation of questions and bug reports? I'm OK with that but for issues I get emails and can just respond in Gmail.

If you guys do not mind getting questions in a form of issues, I am fine with that; no need to bother complicating the setup with discussions.