runserver is confusing
szastupov opened this issue · comments
This isn't particularly a bug but I found it confusing to use runserver and a bit foreign for typical aiohttp apps.
First of all, it seems standard to expose aiohttp.web.Application instance as "app" instead of creating a factory (a practice came from flask, I suppose). Application has call method for compatibility but it doesn't accept any other arguments so it doesn't work with create_main_app() which tries to pass loop to the factory.
Ok, let's assume I made a factory that accepts loop parameter, I'm trying to run it, aaaand stuff breaks because you explicitly create a loop https://github.com/samuelcolvin/aiohttp-devtools/blob/c06eb95d052200b2f3a2d93ca55470048e9d7a20/aiohttp_devtools/runserver/serve.py#L72
Why not use default loop (or at least set it)? some functions like asyncio.ensure_task relies on it.
Thanks!
Have you written unit tests yet?
aiohttp-devtools assumes a function which takes loop as an argument so you can easily write tests that use that function. All the test fixture stuff for pytest (much the easiest way of writing tests for aiohttp code) creates a new event loop for every test (or at least every async def test, which accounts for 99% of aiohttp application tests) and explicitly removes the default loop so you're forced to use the loop which is created for the test and pass a reference to that loop around.
That said, it wouldn't be too hard (as far as i can see right now with a stinking hangover) to modify runserver to accept an app instance instead of a method, however I would still recommend using a function with signature def create_app(loop): -> app to make testing easier.
Should be fixed in #36, @szastupov please review and let me know if you think that's easier.
Looking back on this I think part of the reason app_factory had to be a method with that signature was to make testing aiohttp-devtools easier which is clearly the tail wagging the dog.
Yeah, works as expected 👍 Thanks a lot 🙏
new version 0.2 deployed with the fix.