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

Remove need for aioredis if redis-py is 4.2+ #13

Closed
cunla opened this issue May 22, 2022 · 6 comments
Closed

Remove need for aioredis if redis-py is 4.2+ #13

cunla opened this issue May 22, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@cunla
Copy link
Owner

cunla commented May 22, 2022

Is your feature request related to a problem? Please describe.
Aioredis is now in redis-py 4.2.0rc1+ as described here

Describe the solution you'd like
Default should be not requiring aioredis.

@cunla cunla added the enhancement New feature or request label May 22, 2022
@ikornaselur
Copy link
Contributor

Are there other changes required than introduced by #10?

@cunla
Copy link
Owner Author

cunla commented May 23, 2022

Are there other changes required than introduced by #10?

After #10, the default behaviour is it will try to use aioredis, and if it fails, it will try to use redis asyncio.

I would like the default behaviour to be: if redis version is bigger or equal than 4.2, then import redis asyncio otherwise, try aioredis

@ikornaselur
Copy link
Contributor

ikornaselur commented May 23, 2022

Fair enough, that should only require the similar logic as there is already in place (for aioredis v1 vs v2), right? I'd be happy to make a PR for this 🙏


Edit:

Just looking into this and have few questions:

  • Is there any reason to depend on aioredis at all? The project depends on redis 4.3.1, so there shouldn't be a need to check for the version at all, right? Unless the minimum redis version would be below 4.2.

  • I do have a version running locally that works (tested by manually poetry run pip install redis==4.1 to verify that it does fallback to aioredis), what would be a good way to test this behaviour, if required?

I'm not too well versed in shipping libraries like this, so I would love to learn if there are contexts where redis could be below 4.2 with the latest version of fakeredis-py.

@cunla
Copy link
Owner Author

cunla commented May 23, 2022

Fair enough, that should only require the similar logic as there is already in place (for aioredis v1 vs v2), right? I'd be happy to make a PR for this 🙏

Edit:

Just looking into this and have few questions:

  • Is there any reason to depend on aioredis at all? The project depends on redis 4.3.1, so there shouldn't be a need to check for the version at all, right? Unless the minimum redis version would be below 4.2.

It is possible to use redis below 4.2 with fakeredis - see the actions tab with various options I am testing.
So aioredis should be optional dependency, like lupa.

  • I do have a version running locally that works (tested by manually poetry run pip install redis==4.1 to verify that it does fallback to aioredis), what would be a good way to test this behaviour, if required?

You can tell whether aioredis is used or redis.asyncio is used by using something that only aioredis will have. Something like:

is_aioredis_used = hasattr(aioredis, '__version__') 

I would like to test 4 scenarios:

  1. redis>=4.2 (redis==4.3.1) without aioredis ==> should work fine with redis.asyncio
  2. redis>=4.2 (redis==4.3.1) and aioredis==2.0.1 ==> ensure aioredis is not used
  3. redis<4.2 (redis==4.1) and aioredis==2.0.1 ==> Already exists
  4. redis<4.2 (redis==4.1) and aioredis==1.3.1 ==> Already exists
  5. redis<4.2 (redis==4.1) without aioredis ==> should output a proper error.

This might be a bit more than what you signed up for - let me know. I was planning to work on it this week :)

I'm not too well versed in shipping libraries like this, so I would love to learn if there are contexts where redis could be below 4.2 with the latest version of fakeredis-py.

fakeredis does not require redis to be latest, so it is possible.

@ikornaselur
Copy link
Contributor

ikornaselur commented May 24, 2022

Thanks for all the info! This might potentially be more than I anticipated, but I might take a crack at it tonight. Don't feel like you need to wait for me to submit anything though, as if I don't find time tonight I won't have time until the weekend, at which time you'll have had time to work on it anyway 🙏

I just have couple of follow up questions:

So aioredis should be optional dependency, like lupa.

I see that in #12 you migrated to poetry, where before you did have lupa and aioredis as optional in your setup.cfg:

[options.extras_require]
lua =
    lupa
aioredis =
    aioredis

but it doesn't seem to be the case in the pyproject.toml today with Poetry, unless there is some different way that I'm not aware of to mark them as optional. As per the poetry documentation that's how extras are 'expected' to be defined at least - if there's a different way it's specified in this project then I'd love to learn about that.

fakeredis does not require redis to be latest, so it is possible.

I also see that in the setup.cfg removed in #12 it does say

install_requires =
    ...
    redis<=4.3.1

which matches what I see in a project that uses fakeredis

❯ poetry show fakeredis
name         : fakeredis
version      : 1.7.5
description  : Fake implementation of redis API for testing purposes.

dependencies
 - packaging *
 - redis <=4.3.1
 - six >=1.12
 - sortedcontainers *

but with the move to poetry, I'm only seeing a pin to 4.3.1 in pyproject.toml, so similar to the previous question, are you specifying the optional and more lenient requirements somewhere else now?

@cunla
Copy link
Owner Author

cunla commented May 24, 2022

Yeah, that move to optional dependencies is indeed something that needs to be done as well - I will open another issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants