Should we get rid of `Lifespan` and `LifespanMiddleware`? about asgi-lifespan

[florimondmanca]

Personally, I've only used this package to use LifespanManager alongside HTTPX for testing ASGI apps.

@euri10 described this use case in #13 (comment) as well.

So… are Lifespan and LifespanMiddleware not actually useful in practice?

[florimondmanca]

Essentially we'd end up with this package being re-branded as "asgi-lifespan: Send lifespan events into ASGI apps".

[florimondmanca]

Note that this would make #22 stale. That issue is a good example that we're actually following what Starlette does with its lifespan API, so we're definitely better off leaving it there…

[euri10]

Personally, I've only used this package to use LifespanManager alongside HTTPX for testing ASGI apps.

@euri10 described this use case in #13 (comment) as well.

So… are Lifespan and LifespanMiddleware not actually useful in practice?

my 2 cts, since they seem "built-in" into frameworks that may be the case, however pure-asgi apps if people write them may still love the implementation

[euri10]

encode/starlette#799 will likely change starlette lifespan handler implementation, question is how this package interacts with it once the lifespan part does different things ?

[florimondmanca]

Thanks for your input @euri10 :-)

encode/starlette#799 will likely change starlette lifespan handler implementation, question is how this package interacts with it once the lifespan part does different things ?

Well, in theory it shouldn't change anything on our side. Any user that uses our Lifespan should be able to continue to do so even if they use some Starlette components in the way… But I think it doesn't make much sense for those users to add another dependency to benefit from something that Starlette has built-in, right?

I think my gut-feeling answer to

if people write them

is that they don't. Eg tartiflette-asgi uses Starlette's Lifespan and Router (now merged into one believe) for the implementation of TartifletteApp. Even if I didn't use the Router, I'd certainly use Starlette's lifespan implementation because I could just reach out to the other ASGI stuff built into Starlette (e.g. its types module that's very useful for type hints).

So I'm starting to be a "yes" on this question here — no need to duplicate functionality.

I think a fair plan would be to issue a down-scoped, rebranded 1.0 release of this package with just LifespanManager, and point people at Starlette if they want application-side lifespan support.

[euri10]

Well, in theory it shouldn't change anything on our side. Any user that uses our Lifespan should be able to continue to do so even if they use some Starlette components in the way… But I think it doesn't make much sense for those users to add another dependency to benefit from something that Starlette has built-in, right?

I'm not sure of this but let's try to phrase it as best as I can: if Starlette's lifespan implementation (then subsequently FastAPI one) uses this new yield approach, and this package doesn't, won't we have an issue in tests using httpx+LifeSpanManager where the tests won't behave the same way the app does ?

I think a fair plan would be to issue a down-scoped, rebranded 1.0 release of this package with just LifespanManager, and point people at Starlette if they want application-side lifespan support.

agreed 100% !

[florimondmanca]

won't we have an issue in tests using httpx+LifeSpanManager where the tests won't behave the same way the app does ?

We shouldn’t, no, because we’re all based on the ASGI spec. Starlette switching to a yield API doesn’t change the contents and order of the ASGI messages that it will respond to/send back. So we LifespanManager should be fine. :)