Cutting a Release about stripity-stripe HOT 16 CLOSED

Because of #776 I am cutting a v3

I hope I do not get backlash, too long without releasing, too many changes, and the original author isn't available to own the situation.

I am trying my best to help you all.

from stripity-stripe.

Done @yordis!

from stripity-stripe.

You should be safe to create a new release. The deployment workflow will automatically trigger when a new release is published and it will pass (hopefully yay!) or fail, which won't cause any harm.

I'm not sure the best version for this though.

from stripity-stripe.

Are you going to make a release soon?

from stripity-stripe.

I'll chime in here to detail some of the history.

I wrote https://github.com/maartenvanvliet/striped which is a Stripe SDK in Elixir. Originally the goal was to write a library with the building blocks to generate SDKs based on OpenAPI specs but I never got around to that. Turns out many specs are subtly different enough that custom code is needed for every one to get the best client out of it. So, I just kept it to Stripe.
The code-gen in my library is also straight to compiled code, inspired by this repo https://github.com/wojtekmach/openapi/tree/master and it did what I needed it to do.

Much of the code in my library ended in this repo after a discussion, though with changes to keep some compatibility with how Stripity-Stripe worked in v2. So that's how we end up here.

Back to the issue, I can totally see your view that the compiled approach makes it harder for maintenance and debugging issues. Checking in generated code would definitely help here.

Going forward I see two approaches:

The first one is to write the currently generated code to disk. My initial goal for my building blocks library was to add this as an option as well. Downsides are that the generated code is not very idiomatic. Lot's of unnecessary parens for example but also the generated code relies on stuff being evaluated at compile time. These end up as if false do in the module body so it'll be compiled away but not very nice to read.
It'll be very quick to get this up and running.

The other approach is to use string templates. This gives complete control over the output but would require some changes in how code is generated.

My preference for now lies with the first approach, mostly because it makes it easier for a release to be made soonish. I can make a PR if you wish.

I'll see if I can help out with some of the open issues.

from stripity-stripe.

Thank you for the release! ❤️ ❤️ ❤️

from stripity-stripe.

@doomspork could you help me over here?

from stripity-stripe.

any word on cutting a release?

from stripity-stripe.

Sorry, peeps are busy lately. I am going to continue the work once they unblock me.

from stripity-stripe.

Firstly, I must say, the package's recent introduction of the feature to code-gen the entire SDK from the OpenAPI is truly exceptional! It's this sort of invention that motivated me to help the new EEF working group focusing on OpenAPI generators for prevalent packages and close the topic together across the ecosystem; by now, I have seen it all, I believe.

However, I've observed a potential issue and I'm hoping we can brainstorm solutions together. It appears the process goes directly from file to final code at compile-time, without a clear verification step for the generated code. This brings up a couple of concerns:

1. Assisting others when an issue arises becomes a bit challenging. If something doesn't go as planned, there's no specific line of code users can point to for help. The stack trace only provides meaningful insights if I possess the same SDK version they generated.

2. Online documentation currently seems to lead to dead ends. Most of the GitHub links appear broken, primarily because the compiled code from the file isn't checked in, which affects the overall usability.

I'm interested in understanding the reasoning behind this approach and why the decision was made to avoid checking in the code-gen code, relying instead on compile-time.

More importantly, I'm curious to know your thoughts on possibly reconsidering this decision. We could still make good use of the code-gen tool, but perhaps we could consider outputting the code and checking it in, as a way to address the concerns I've raised.

I genuinely respect and value your decisions, and my intention is simply to help mitigate any potential issues moving forward.

In my experience, finding a middle ground often yields the best results. I would love to hear your thoughts on this matter.

Looking forward to your feedback!

from stripity-stripe.

@beam-community/team I need your direction here, I wouldn't like to feel bad for making a decision that then backfires on me. I have my opinions but I know the combined thoughts will produce a better outcome.

Please help 🙏🏻

from stripity-stripe.

Seeing the SDK generation is encouraging, even if it might not be perfect yet. After all, what truly matters to us is sparing everyone from the laborious process of hand-writing the client and ensuring a positive developer experience. As for the current quality of the code-gen, it's not my primary focus.

I genuinely value and care about seeing the tangible output saved to the disk and committed. That progress is significant to me!

I can make a PR if you wish.

If you know how to accomplish the most basic "write-to-disk", by all mean help me here!

from stripity-stripe.

https://github.com/beam-community/stripity-stripe/actions/runs/5925955972/job/16066421114#step:6:369

account not authorized for this action

@beam-community/team hey, we can not publish to Hex. I am not sure how to help here!

from stripity-stripe.

A good idea to fix #800 before cutting off a v3

from stripity-stripe.

Folks, I can not publish to Hex still, I need help here @beam-community/team

from stripity-stripe.

@begedin @snewcomer, it seems you are owners of the package, so you may be able to help here 🙏🏻

from stripity-stripe.