Feature Request: Consider using tenacity for retrying logic

[Skeen]

Hello,

I don't know which considerations were applied when this library was designed, and whether keeping dependencies to an absolute minimal is a requirement, but if this is not the case, would it be worth considering utilizing https://github.com/jd/tenacity for the retrying logic, rather than implementing it from scratch?

If such an approach was taken, this library would essentially minimize itself to solely gluing tenacity and aiohttp together, and it would enable using all retrying options from tenacity rather than the subset which is available here.

[inyutin]

@Skeen hello!

This project grew out of a little piece of code we needed at work a long time ago. I didn't know about tenacity at the time and it was easier for me to write a wrapper than to adapt solutions for retries. Moreover I'm still don't know anything about them. Moreover, I still know nothing about tenacity and I'm don't use it.

Personally I think that libraries should be quite wide in their api. It's a good think that aiohttp_retry provide it's own way to define retry logic. I'm sure that this api is good and straightforward and suites most of the needs. On the hand, I'm agree that the library should be easily adopted by the solutions of other libraries. In other terms I'm sure it will be great to have a bridge between aiohttp_retry and tenactiy.

To be honest I don't want to invest my time into understating how tenacity works and it's api. I will be glad if someone will open a good PR to implement tenacity behaviour in aiohttp_retry. The way I see it is that it should be a special RetryOptions class for that. This class should receive a tenacity object, that defines retries, and then implement get_timeout function with the using of this function.

I will be appreciate if someone would do such a thing.