Sentinel commands have migrated in redis main

[sarathak]

Redis pre release test throwing error in CI

• Test Python 3.9, Django 3.2, Redis.py master
• Test Python 3.9, Django 3.2 main, Redis.py master

  self = Sentinel<sentinels=[127.0.0.1:26379]>, service_name = 'default_service'
  
      def discover_master(self, service_name):
          """
          Asks sentinel servers for the Redis master's address corresponding
          to the service labeled ``service_name``.
      
          Returns a pair (address, port) or raises MasterNotFoundError if no
          master is found.
          """
          for sentinel_no, sentinel in enumerate(self.sentinels):
              try:
  >               masters = sentinel.sentinel_masters()
  E               AttributeError: 'Redis' object has no attribute 'sentinel_masters'
  
  .tox/py39-dj32-redismaster/lib/python3.9/site-packages/redis/sentinel.py:211: AttributeError
  _____ ERROR at teardown of DjangoRedisCacheTestEscapePrefix.test_iter_keys _____
  
  self = <tests.test_backend.DjangoRedisCacheTestEscapePrefix testMethod=test_iter_keys>
  
      def tearDown(self):

[WisdomPill]

hello @sarathak,
redis master is allowed to fail as there might be new unreleased changes that will break the library.
Have you had look at what this might be?
Are you open to make changes to solve this for newer version of redis-py?

[sarathak]

@WisdomPill

my opinion is we have to remove pre release test from CI

[WisdomPill]

why one earth would you want to do that?

pre releases is added for this very reason, so that we know that before releasing a new version we have to solve some issues first to support the next version of redis

[WisdomPill]

In this case, sentinel and cluster commands have moved to it's own mixins, have a look here. New commands are found here

[chayim]

We're planning on releasing a new redis-py in the short-term. This is a great catch that your project has in its pipeline, I highly recommend maintaining these tests. Note: We haven't broken the API itself, but I'd like to go down the path of more restructuring in the mid-term.

[WisdomPill]

@chayim thanks for the notice.
Can you elaborate what kind of restructuring you have in mind? Just so we can get an idea of what and where do the changes.
Is this new version going to be a major release or not?

[chayim]

Absolutely! In the short term - nothing. There's just these mixins. In the long-term we'd like to get better cluster support, the string argument building in place, etc. General goal is to *never* break an API. Originally, I was pushing for the next release to be 3.6, but given that there are many changes, and that projects have frequently pinned >=3.5.3 && < 4.0.0, I think 4.0 and onwards makes sense.

…

[WisdomPill]

@chayim do you ming changing the version (here) of redis-py in master so that we could start adapting the code to handle the recent changes?

or I could open a PR to do it.

[chayim]

@WisdomPill In prep for 4.0.0, I just pushed up a 3.9.9 placeholder version.

For anyone not pulling directly from master that's no effect (or release), but this should solve the ask. Also, thank you for the pointer about the commands migrating in redis main - I'm going to update the changelog accordingly for breaking changes.

[WisdomPill]

Thank you very much!

[chayim]

@WisdomPill they're about to migrate again now that the 4.0.0.beta1 is out. Just a heads up. Similarly I'm about to deprecate python 3.5 support for redis. I noticed that this, and celery both use python > 3.6 (as we should), but I wanted to give you a heads up.

[WisdomPill]

Thanks for the heads up!