`trio` support broken: unexpected keyword argument 'auth_manager'

[burnpanck]

It appears that trio support is currently broken. The following basic example fails:

async with aiogoogle.Aiogoogle(
    session_factory=aiogoogle.sessions.trio_asks_session.TrioAsksSession,
) as gcp_api:
    storage = await gcp_api.discover("storage", "v1")

->

TypeError: TrioAsksSession.send() got an unexpected keyword argument 'auth_manager'

It looks like auth_manager is something requests-specific which potentially was just implemented recently?
This was tested under python 3.12.2 with the following versions:

• trio: 0.24.0
• aiogoogle: 5.7.0
• asks: 3.0.0

[omarryhan]

Hi @burnpanck , It’s likely that support for Trio & Curio got broken. I’ve been only approving PRs and not actively maintaining the repo. Also, I didn’t feel like there’s much demand for loops outside asyncio. That’s why I wasn’t investing much in testing them.

But I’d say the changes since I last personally tested these 2 loop providers were minimal. So should be easy to patch. It would be amazing if you can help me with that! And I’ll do my best to approve and deploy your changes. Thanks!

[burnpanck]

I didn’t feel like there’s much demand for loops outside asyncio.

People don't realise what they miss! With trio, I don't have a single exception that accidentally ends up on stderr. With asnycio, that happens all the time.

Anyway, I'm happy to help in this regard. What exactly is that auth_manager argument supposed to do? I was just trying to monkey-patch TrioAsksSession to accept that argument and simply assert auth_manager is None, but then I did run into other issues. It appears that asks is unmaintained, and fails to work with a recent trio. I'll probably just write a new session manager for httpx using anyio, doesn't look too complicated.

[omarryhan]

Yup, it’s not too complicated. But auth manager is important, it’s the object responsible for authenticating the requests being sent. @burnpanck