Support alternate HTTP Libraries? - Ethon issues on macos

[bmo]

There are open issues with using Ethon on macos, e.g. typhoeus/ethon#206

Our developers are not able to use the library on macos w/o changing the hubspot-api-ruby gem, which is out of scope for their work.

Would be nice to use libraries that enjoy more consistent usage (and therefore, fixes) by macos users in the Ruby community, perhaps faraday, HTTParty, rest-client...

[plaurynovich-hubspot]

Hi, @bmo. It looks like the next http client for this gem is going to be Net::Http. Thank you.

[abepetrillo]

@plaurynovich-hubspot Any progress on this. We've just hit a nasty bug related to what @bmo is experiencing.

[vishnun]

Also looking for an update on this

[timherby]

We would like to use this library, but cannot use it with Typhoeus. Any updates, @plaurynovich-hubspot on whether switching to Net::Http is a priority still?

[timherby]

@alzheltkovskiy-hubspot, could you help me contribute the fix to this project to get a Typhoeus-free version of this gem?

My company is in proof-of-concept with HubSpot and looking to go live soon. The challenge is that we are running into crashes on Mac M1/M2s due to this issue typhoeus/ethon#234 (or the many like it that appear

I have done an extensive investigation, and it is clear that Typhoeus and Ethon are no longer maintained. I see that Faraday is an option for the ruby generator, and would like to take a shot at updating my fork of this gem, and potentially contributing it back as a PR for the issue in this thread.

What I'm perplexed by is how the code generation for this gem happens. I do not see any configuration or scripts to run the code generation with https://openapi-generator.tech/. I do see that HubSpot has posted their API definition here https://api.hubspot.com/api-catalog-public/v1/apis, but I'm stuck on figuring out how to go from that to updating this library.

Could you kindly point me to the documentation on how to contribute to this project or at least how to run the code generation on my own fork?

Thanks in advance!

[atanasiuk-hubspot]

Hey @timherby, thanks for bringing this up,

Switching to Faraday might be an option here, however, assuming we're using OpenApiGenerator, it might introduce new bugs and/or breaking changes to the client, so most likely it's not going to be a quick fix and, therefore, a short-term solution.

Could you kindly point me to the documentation on how to contribute to this project or at least how to run the code generation on my own fork?

Unfortunately, there is no public instructions at this point, some internal tools together with some manual adjustments are in use. What we can do here is to generate the client with Faraday, push the results into a separate branch, allowing you to test it and use on your own for now. Does it make sense?

[timherby]

@atanasiuk-hubspot that would be great. I'd love to test that branch if you can do that. Sounds like a good way for you to validate on the side if it works. Please let me know once you have a branch, and I'll switch to it.

[jausura]

Hi @timherby I'm the product manager for the SDKs team. I apologize for not giving you an update on this. Just wanted to let you know that it has not gotten totally lost. We'll give you an update on the plan/timing tomorrow.

[timherby]

Hi @jausura. Thanks for letting me know. Looking forward to the update.

[jausura]

@timherby I spoke with the team this morning about when we could get started on this fix. We should have bandwidth next week to implement the branch solution discussed above. It's unclear exactly how complex that will be so we'll keep you posted on when it's ready for use. After that we can explore updating the SDK, but it's my understanding that could be a significant piece of work. So we'll concentrate on the branch solution for now to get you unblocked.

[timherby]

Thanks @jausura. The branch solution will work for us, and will allow us to validate the approach. I'm glad to hear you will hopefully be able to deliver this next week.

[atanasiuk-hubspot]

Hi @timherby! The faraday version is available in this branch.
While we're validating the solution, would you be able to check if switching to faraday resolves the issue on your end?

[timherby]

Thank you very much @atanasiuk-hubspot . I have tested this and it works locally! No crash on Mac M2 anymore.

We will need some time to validate and get it into production (since it requires Faraday 2.x and we're on 1.x, so we have some gem upgrades to sort through). I'll get back to you if I run into any issues.