Faraday 1.9 broke the ruby 2.5 compatibility
Closed this issue · 17 comments
Basic Info
- Faraday Version: 1.9.0
- Ruby Version: 2.5.x
Issue description
Version 1.9.0 bumped the minimum ruby constraint breaking the compatiblity with ruby 2.5
I understand that 2.5 is EOL, but such end of support is equivalent to a breaking change IMHO.
Was the bump of the constraint important/mandatory?
If not, do you think it would be possible to yank/republish a 1.9 version (or a 1.9.1) with 2.5 support?
Thanks in advance
I had to drop it to support v2 of the adapters, but I reverted that in 1.9.1, so I can look into re-adding support for Ruby 2.5 if it's not a big effort.
It's worth pointing out though that our support strategy would have allowed this:
This library aims to support and is tested against the currently officially supported Ruby implementations.
This means that, even without a major release, we could add or drop support for Ruby versions,
following their EOL. Currently that means we support Ruby 2.6+
That said, I understand there are people running outdated Ruby versions in some projects, so I'll see what we can do and eventually release a 1.9.2 version with support added back
FWIW I appear to have the same issue as @sombrerosheep on Ruby 2.6.5 when using faraday 1.9.1.
/opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/faraday-1.9.1/lib/faraday/request/retry (LoadError)
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit/default.rb:28:in `block in <module:Default>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/faraday-1.9.1/lib/faraday/rack_builder.rb:76:in `build'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/faraday-1.9.1/lib/faraday/rack_builder.rb:65:in `initialize'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit/default.rb:27:in `new'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit/default.rb:27:in `<module:Default>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit/default.rb:9:in `<module:Octokit>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit/default.rb:6:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/octokit-4.21.0/lib/octokit.rb:4:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/request_sources/github/github.rb:5:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/ci_source/local_git_repo.rb:6:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/commands/init.rb:3:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/commands/runner.rb:3:in `<class:Runner>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/commands/runner.rb:2:in `<module:Danger>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger/commands/runner.rb:1:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/lib/danger.rb:4:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/lib/ruby/gems/2.6.0/gems/danger-8.2.3/bin/danger:4:in `<top (required)>'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/bin/danger:23:in `load'
from /opt/hostedtoolcache/Ruby/2.6.5/x64/bin/danger:23:in `<main>'
Not totally sure if it's relevant to this issue, though
This occurs when after running gem install danger and then trying to run the danger gem, but it appears to be faraday that's unable to load 🤔
@connorshea that's a different issue, it seems like oktokit is using the fully-qualified class name for the faraday-retry middleware instead of the alias. It would be an easy fix for them, but there might be other gems with the same issue so I'll try to fix it on our side
I can confirm 1.9.2 fixes my problem, thank you! 🙇
Thanks for reporting back ❤️ !
For what it's worth, I think the original issue with Ruby 2.5 compatibility is still relevant (although it doesn't effect me), sorry for hijacking this issue with a separate problem 😅
Ups! didn't mean to close this!
Faraday 1.8.0 used to expose Faraday::UploadIO.
An alias Faraday::UploadIO = Faraday::Multipart::FilePart would be appreciated to maintain compatibility in octokit.
@julian-berbel that alias have been added to faraday-multipart and released in v1.0.2 👍
Awesome, thanks a bunch!
We're also being impacted by the drop of Ruby 2.5 in a Y version, fwiw. We would also consider this a breaking change, that our pinning would have protected us from had this been done in a major release.
It's worth pointing out though that our support strategy would have allowed this:
This library aims to support and is tested against the currently officially supported Ruby implementations. This means that, even without a major release, we could add or drop support for Ruby versions, following their EOL. Currently that means we support Ruby 2.6+
@iMacTia FYI: It looks like the following sources of Faraday docs have conflicting info about the supported Ruby versions:
- https://www.rubydoc.info/github/lostisland/faraday/file/README.md says Ruby v2.4+
- https://github.com/lostisland/faraday/blob/main/README.md#supported-ruby-versions says Ruby v2.6+
- https://github.com/lostisland/faraday/blob/1.x/README.md#supported-ruby-versions says Ruby v2.4+
- https://github.com/lostisland/faraday/blob/main/CHANGELOG.md looks like it hasn't been updated in a while
- https://github.com/lostisland/faraday/releases doesn't appear to document any recent changes to the supported versions
@iMacTia The removal of support for Ruby v2.4 from faraday-retry is currently breaking some of our automation. We'd like to see that regression fixed ASAP.
Ruby 2.4+ support (I felt generous so I went back one more version 😂) has been re-added a released with Faraday 1.9.3 🎉
Closing this for now but feedback welcome if you can give it try 👍
(although please don't expect me to read until tomorrow morning as it's getting late here 😅)
Thank you for the quick response! I'll give it a shot.
Ruby 2.4+ support (I felt generous so I went back one more version 😂) has been re-added a released with Faraday 1.9.3 🎉 Closing this for now but feedback welcome if you can give it try 👍 (although please don't expect me to read until tomorrow morning as it's getting late here 😅)
Much thanks @iMacTia . Looks like v1.9.3 is working OK with our existing automation. We appreciate the quick response!