berkes
commented
2 years ago I'd like to add an alternative: not depend on any HTTP client, but leave that to the implementor.
For me, gems that depend on specific (versions of) HTTP clients, is very unfortunate:
- It pulls in a lot of dependencies that I have no control over (Faraday depends on 4+ other gems)
- It conflicts with other versions.
- It makes debugging and maintainance a hell if we thus get several different gems.
My use-case is not the most common but not that unusual either:
We have a storage layer that offer people to store files on their preferred platform: S3, GoogleDrive, Dropbox, FTP etc. We integrate many cloud APIs.
Many of the gems for these platforms come with their own (version of) HTTP clients. For example, I now have to maintain a dependency tree with net/http, faraday, excon, typhous, and httparty. We had to forego a (rather crappy) GoogleDrive/GC, gem because it required a faraday version incompatible with this gem here.
Alternatives, I would love to see considered are:
- A generic adapter-like setup. E.g. https://www.ruby-toolbox.com/projects/httpi offers a generic layer over all popular HTTP clients: the implementor can inject their preferred libs.
- Rely on net/http only. Ruby STDlib http client is cumbersome, but it is available and consistent to all without conflicting. E.g. AWS::S3 uses this method.
Sorry for the long winded post. Hopefully this is something worth considering. If so, I can probably find some time to code this, though not on short notice.
And, in case I come over as critical: not at all: I love this great Gem!
jrochkind
Jesus
dropbox_api gemspec has a dependency on
'faraday', '~> 1.0'.Faraday 2.0.0 was released on Jan 4 2021.
An app using dropbox_api (or anything that depends on it) can't upgrade to faraday 2.0 unless/until dropbox_api's specification is relaxed.
Could dropbox_api be verified and released for faraday 2.0?
https://github.com/lostisland/faraday/blob/main/UPGRADING.md