Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support Faraday 2.x #355

Closed
jrochkind opened this issue Jan 10, 2022 · 4 comments · Fixed by #365
Closed

support Faraday 2.x #355

jrochkind opened this issue Jan 10, 2022 · 4 comments · Fixed by #365
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@jrochkind
Copy link

googleauth gemspec has a dependency on "faraday", ">= 0.17.3", "< 2.0".

Faraday 2.0.0 was released on Jan 4 2021.

An app using googleauth (or anything that depends on it) can't upgrade to faraday 2.0 unless/until googleauth's specification is relaxed.

Could googleauth be verified and released for faraday 2.0?

https://github.com/lostisland/faraday/blob/main/UPGRADING.md

@yoshi-automation yoshi-automation added triage me I really want to be triaged. 🚨 This issue needs some love. labels Jan 11, 2022
@renchap
Copy link

renchap commented Jan 20, 2022

As an alternative to upgrading to Faraday 2, please consider dropping the dependency on Faraday, as it often results in conflicts with other gems or apps that use Faraday and major version bumps might be hard to manage.

@dleavitt
Copy link

dleavitt commented Feb 9, 2022

Here's some prior art from Sentry, who switched their Ruby client from Faraday to net/http in response to the 2.0 release:
getsentry/sentry-ruby#1678

They retained the ability to use Faraday via making the transport layer pluggable. Seems like a good approach!

@jrochkind
Copy link
Author

jrochkind commented Feb 9, 2022

Faraday as I understand it was already meant to be a pluggable transport layer you can re-use.

Faraday 2.0 is pretty backwards compat, just a few tweaks. Replacing it with your own home-built "pluggable transport layer" would be a lot more work than just upgrading to faraday 2, and based on lack of response to this issue I'm guessing there isn't a lot of maintenance energy behind this gem....

I'm not sure I understand why sentry decided faraday 2.0 was "major changes" that justified a switch.

I'd be happy with either personally, anything that lets me use faraday 2.x in my project that also has this in my dependency tree! I suspect just supporting faraday 2.x as well as 1.x will be the least work.

If this project currently has CI with good coverage that's working and green (haven't checked), and if a committer shows up to say they're paying attention and would review, I could probably find time to submit a PR allowing both faraday 1.x or faraday 2.x. (I have successfully modified other gems to allow faraday 1.x as well as 2.x)

But either change is fine with me if someone else does it; and neither change is going to happen if the committers are missing in action!

@dazuma
Copy link
Member

dazuma commented Feb 15, 2022

I'm pretty sure we can relax the gemspec to allow faraday 2.x.

@dazuma dazuma added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. and removed triage me I really want to be triaged. 🚨 This issue needs some love. labels Feb 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants