Stripe gem requires a compiler

[mperham]

RestClient pulls in 5 different gem dependencies, including a native gem so I have to install a compiler on my server to install the Stripe gem. This seems pretty heavyweight for an HTTP API. Would it be possible to use Net::HTTP with a few helper methods instead and remove this dependency?

Building native extensions.  This could take a while...
Successfully installed unf_ext-0.0.7.1
Successfully installed unf-0.1.4
Successfully installed domain_name-0.5.24
Successfully installed http-cookie-1.0.2
Successfully installed netrc-0.10.3
Successfully installed rest-client-1.8.0

[russelldavis]

Hi @mperham, thanks for raising the issue. I don't think this is a priority for us right now. Even the json gem uses native extensions.

If you're just concerned about the unf_ext gem, you can force an older version of rest-client in your Gemfile (that dependency is downstream from the new http-cookie dependency in rest-client 1.8).

[mperham]

Understood, I'm fighting the good fight against unnecessary and complex dependencies.

On May 30, 2015, at 11:41, Russell Davis [email protected] wrote:

Hi @mperham, thanks for raising the issue. I don't think this is a priority for us right now. Even the json gem uses native extensions.

If you're just concerned about the unf_ext gem, you can force an older version of rest-client in your Gemfile (that dependency is downstream from the new http-cookie dependency in rest-client 1.8).

—
Reply to this email directly or view it on GitHub.

[yob]

Is there specific functionality of RestClient that stripe depends on? I'm interested in minimising the dependencies in our apps, so might be willing to work on a PR that switches to Net::HTTP if there was interest.

I'd be inclined to make it an option (with RestClient as the default) to begin with, and work towards making Net::HTTP the only option when everyone was confident with it.

[brandur]

Is there specific functionality of RestClient that stripe depends on? I'm interested in minimising the dependencies in our apps, so might be willing to work on a PR that switches to Net::HTTP if there was interest.

@yob Hey! Not to my knowledge, but there is the problem that because we didn't really provide a way to set various request options, people have probably started injecting them to RestClient directly, so switching out the underlying client may be a pseudo-breaking change for some users (see #124 for an example of this). But I like your proposal of keeping both options in the library for the time being.

See also #313 for more considerations around changing the client out. There are a couple "nice to haves" that we might want to put in as we make this change.

I'd be inclined to make it an option (with RestClient as the default) to begin with, and work towards making Net::HTTP the only option when everyone was confident with it.

Nice! If you're willing to assemble a patch, I'm more than happy to take a look at it and work to get it mainline. Thanks!

[yob]

Thanks for the pointer to #313, I missed it somehow.

Going by that, it sounds like your preference would be to have a way to choose an HTTP backend, rather than just switching to Net::HTTP as the only option?

[brandur]

Going by that, it sounds like your preference would be to have a way to choose an HTTP backend, rather than just switching to Net::HTTP as the only option?

That would probably have been my default choice given that (1) you'd get some advantages in extensibility by moving to something like Faraday (i.e. middleware), and (2) Net::HTTP's somewhat unfortunate interface has led to a proliferation of these alternate HTTP clients anyway, so Ruby developers tend to be familiar with them.

That said, I'd definitely hold off on making a final decision there until trying out a few implementation options. It's possible that doing something on Net::HTTP still get us all the things we want and I do like the idea of removing all of stripe-ruby's dependencies.