nateware / redis-objects

Map Redis types directly to Ruby objects
Artistic License 2.0
2.09k stars 229 forks source link

About the `"redis", "< 4.6"` version constraint #265

Closed Drowze closed 2 years ago

Drowze commented 2 years ago

Hello,

I've been using the version 1.5.1 of this gem for a while along with redis-rb version 4.6 without any issues apart from this kind of warning:

Pipelining commands on a Redis instance is deprecated and will be removed in Redis 5.0.0.

redis.pipelined do
  redis.get("key")
end

should be replaced by

redis.pipelined do |pipeline|
  pipeline.get("key")
end

(called from /Users/Drowze/asdf/installs/ruby/3.0.2/lib/ruby/gems/3.0.0/gems/redis-objects-1.5.1/lib/redis/objects/sets.rb:33:in `block (2 levels) in set'}

I see that recently this commit https://github.com/nateware/redis-objects/commit/53acbae7844311c19a3e424e57414813959e4a2d added a < 4.6 version constraint for redis-rb, making the version 1.6.0 of this gem incompatible with redis-rb 4.6.

Is there any known issue to use redis-objects with redis-rb 4.6 (besides warnings)? I'd prefer to have the version constraint removed otherwise if that is ok. Please note that one can silence all redis deprecation warnings (although discouraged) by setting Redis.silence_deprecations = true (source)

nateware commented 2 years ago

Thanks for raising this issue. Because the API changes are incompatible, I felt like the version lock was the best course of action. Is there specific functionality that you lose from redis-rb?

On Mon, May 23, 2022 at 3:15 AM R Gibim @.***> wrote:

Hello,

I've been using the version 1.5.1 of this gem for a while along with redis-rb version 4.6 without any issues apart from this kind of warning:

Pipelining commands on a Redis instance is deprecated and will be removed in Redis 5.0.0.

redis.pipelined do redis.get("key") end

should be replaced by

redis.pipelined do |pipeline| pipeline.get("key") end

(called from /Users/Drowze/asdf/installs/ruby/3.0.2/lib/ruby/gems/3.0.0/gems/redis-objects-1.5.1/lib/redis/objects/sets.rb:33:in `block (2 levels) in set'}

I see that recently this commit 53acbae https://github.com/nateware/redis-objects/commit/53acbae7844311c19a3e424e57414813959e4a2d added a < 4.6 version constraint for redis-rb, making the version 1.6.0 of this gem incompatible with redis-rb 4.6.

Is there any known issue to use redis-objects with redis-rb 4.6 (besides warnings)? I'd prefer to have the version constraint removed otherwise if that is ok. Please note that one can silence all redis deprecation warnings (although discouraged) by setting Redis.silence_deprecations = false ( source https://github.com/redis/redis-rb/blob/master/CHANGELOG.md#460)

— Reply to this email directly, view it on GitHub https://github.com/nateware/redis-objects/issues/265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABZICIJOOJKZ5JKZTLA3LVLNLD3ANCNFSM5WVJ6G3A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Drowze commented 2 years ago

Hey @nateware sorry for taking so long!

There isn't any specific functionality from redis-rb 4.6 that I am missing. I am, however, trying to make sure that my application code is ready for redis-rb 5 (when it is released), so having the warnings being triggered on my own application code is useful so I can be sure not to use deprecated commands. I understand that redis-objects is not (yet) ready for redis-rb 5 and that's fine - I can tolerate the deprecation warnings coming from redis-objects code - but I don't see why is redis-objects incompatible with redis-rb 4.6 just because of such warnings 🤔

In my opinion and unless I'm missing something, redis-objects 1.6.0 is fully API compatible with redis-rb 4.6 - it's just using some deprecated commands (and therefore is not ready for the next major change i.e. redis-rb 5). I think instead of a version constraint, a section on the README regarding the warnings is just fine (and anyone who's really annoyed about the deprecation warnings can either silence them with Redis.silence_deprecation = true or set a version constraint on their own Gemfile).

md-farhan-memon commented 2 years ago

Today, I ran into this problem too but in a more obstructive way due to dependency of another gem I have been using already. What is the elegant solution here? Any help would be appreciated as I am stuck here.

Bundler could not find compatible versions for gem "redis":
  In snapshot (Gemfile.lock):
    redis (= 4.6.0)

  In Gemfile:
    redis-objects was resolved to 1.6.0, which depends on
      redis (< 4.6)

    sidekiq-limit_fetch (~> 4.2) was resolved to 4.2.0, which depends on
      redis (>= 4.6.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
nateware commented 2 years ago

Ok, I reverted the redis-rb version lock and just pushed 1.7.0 to rubygems.