Use anyio for async code, so that users can choose either asyncio or trio backends

[Zac-HD]

👋 Over at @anthropics we're enthusiastic users of both Slack and async Python - but instead of asyncio we use structured concurrency with Trio.

This makes using slack-bolt's AyncClient pretty awkward, because now we have multiple async backends running, can't use our standard helper functions, and things generally start going wrong. Building a copy of the whole stack for each backend isn't feasible (thus also sans-io designs), and hence this request to support using either asyncio or trio as the backend.

Using anyio makes this pretty easy - just ask e.g. FastAPI! - and it should be fully compatible with existing asyncio-using code. I realize it's not a particularly small task, but Trio is downloaded about 200k times per day and good support for that makes a big difference.

[seratch]

Hi @Zac-HD, thanks for writing in! I also like AnyIO for its approach making async/await code backend framework agnostic easily.

Even though it may be easily feasible to support AnyIO on the surface area, there is still a challenge. As you mentioned, AIOHTTP, which is the core of AsyncClient, does not work with Trio. So, to support Trio properly, this project has to add a new async HTTP client for Slack Web API calls.

The initial development of a new layer for AnyIO and a new Trio-compatible HTTP client may not be so hard. However, we hesitate to prioritize the initiative due to the following reasons:

• I personally know many devs happily use Trio. However, in the last few years, we've never received feedback on Trio support. As long as we don't see the same-level needs with asyncio, AnyIO/Trio related changes to the SDKs are not our priority.
• Our team is now putting most of its energy into new platform features (https://api.slack.com/future), so our bandwidth for Bolt and existing SDKs is quite limited. We need to avoid increasing the maintenance cost of this project.

Therefore, we are not planning to work on this enhancement in the short term (at least for a few months). Even if anyone generously sends a pull request for the feature addition, we may hold off working together to make large changes. In the long run (say, in years), the situations around us can be different, and we may revisit this in the case (That being said, I know that the long-term plan does not mean anything to you).

Thanks again for sharing this feedback! I know this answer is not great for you, but it'd be greatly appreciated if you could understand our situation. Also, if anyone else has some thoughts on this, please feel free to write in this thread.

[Zac-HD]

Thanks for your quick and comprehensive response! I think that sniffio + trio-asyncio could let you keep using aiohttp, but of course that doesn't address the larger context - and as an OSS maintainer I'm always sympathetic to keeping things reasonably scoped. I'll look forward to the long term though 😁