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 started as a small piece of code we needed at work for retries. At the time, I wasn’t familiar with libraries like Tenacity, so I wrote a simple wrapper instead. Even now, I haven’t used Tenacity and am not very familiar with its API.

In general, I believe APIs should be versatile, and it’s great that aiohttp_retry offers its own retry logic. The API is straightforward and should meet most use cases. At the same time, I agree that libraries should be adaptable to other solutions, so having a bridge between aiohttp_retry and Tenacity would be beneficial.

However, I’m not interested in learning Tenacity’s API myself. If someone is willing to contribute a good PR to support Tenacity in aiohttp_retry, I’d appreciate it. My suggestion is to create a RetryOptions class that takes a Tenacity object to define retries, implementing the get_timeout function using this object.