Litestar v3 roadmap

[provinzkraut]

Summary

Litestar v3 is coming soon! 🚀

We’re thrilled to announce that Litestar v3 is on the horizon, bringing a host of exciting new features, improvements, and some breaking changes to make your development experience even better. Here’s what you can expect

Things to do for v3

• Remove StaticFileConfig
• Drop support for implicit Optional Default Parameters
• Replace OpenAPI Controller with Plugins
  • Elimination of OpenAPIController Subclassing
  • Changes to Endpoint Configuration
  • Modification to root_schema_site Handling
• Remove deprecated app parameter for Response.to_asgi_response
• Remove deprecated scope state utilities
• Remove deprecated utility function is_sync_or_async_generator
• Remove of semantic HTTP route handler classes in favour of functional style decorators
• Remove of deprecated litestar.middleware.exceptions module and ExceptionHandlerMiddleware
• Overhaul route handler configuration (feat!: static handler configuration #3900)
• Improve "file system" abstractions (feat: v3 - new file system implementation #4056)
• Remove all deprecated items scheduled for removal in 3.0
• Remove pagination
• Don't use __future__.annotations, only use stringized annotations where strictly necessary / clean up signature namsepaces
• Deprecate plugin protocols in favour of abstract base classes and remove deprecated plugin protocols (feat: Add SerializationPlugin and InitPlugin to replace their respective protocols  #4025, feat(plugins)!: Remove OpenAPISchemaPluginProtocol #4026, feat(plugins)!: Remove CLIPluginProtocol #4027, feat(plugins): Remove deprecated SerializationPluginProtocol #4028, feat(plugins)!: Remove OpenAPISchemaPluginProtocol #4026)
• Use native event loop in AsyncTestClient (Bug: the app for test client is running in a different event loop #1920)
• Drop Python 3.8 support (feat(core)!: drop Python 3.8 support #4010)
• Improve and simplify logging interface (Better Logging Interface (Also simplified) #2858)
• Update sentry integration
• Move built-in middlewares to new ASGIMiddleware (refactor: asgimiddleware everywhere if possible #4055)
• Drop support for Python 3.9
• Add migration guide :)

---

We will update this issue with information about the release, how to prepare, upcoming pre-releases etc.

If you've got any questions, remarks or additions, this is the place to leave them :)

[marcuslimdw]

would it be possible to have more standardisation of acronym capitalisation rules?

@HTTPRouteHandler(..., http_method=[HttpMethod.GET, HttpMethod.POST]) kind of grinds my gears.

(my preference is for only initial caps i.e. HttpMethod because that's more easily scannable/parsable)

[provinzkraut]

would it be possible to have more standardisation of acronym capitalisation rules?

@HTTPRouteHandler(..., http_method=[HttpMethod.GET, HttpMethod.POST]) kind of grinds my gears.

(my preference is for only initial caps i.e. HttpMethod because that's more easily scannable/parsable)

Mmh. I'm not too keen on renaming things simply for optics. It's a breaking change after all, but for a relatively small benefit (specifically in this case, where you'd normally never use HTTPRouteHandler directly).

[marcuslimdw]

I think I'm more thinking in terms of the future - AFAIK, there currently isn't any project-wide convention for this, and it'd be good to set one.

[usama-elm]

Hi, kinda unrelated to the roadmap. But I'd like to start developping an API for a personal project.
Is it ok for me to start developping on the unfinished v3.0 branch or is it better for me to stay on the v2.0 and wait for the migration.

I dont mind any breaking and refactoring if there are any evolving changes as it is a greenfield project.

[euri10]

I dont mind any breaking and refactoring if there are any evolving changes as it is a greenfield project.

I think you answered yourself your question, idk when v3 will be out though but given the sheer amount of tests in the suite you shouldn't have too many issues, and if you have that's cool for us, we have a beta-tester :)

[usama-elm]

Ok perfect, a pleasure to be a beta tester, I don't think I will be hitting a lot of edge cases as I wont initially be using any dependency injection or custom middleware.

[winstxnhdw]

Don't use future.annotations, only use stringized annotations where strictly necessary / clean up signature namsepaces

What's the reason for this decision?

[provinzkraut]

Don't use __future__.annotations, only use stringized annotations where strictly necessary / clean up signature namsepaces

What's the reason for this decision?

To reduce the reliance on signature namespaces. The issue is that if Litestar internally uses __future__.annotations (or other stringized annotations), it has to resolve those strings again when it wants to do something with those types, which Litestar does a lot. This process however is actually not entirely deterministic, and can lead to weird bugs. It's also quite hard to get just right.

So the easier thing is, at least for Litestar itself, to just not use these. For end-user applications, the cases where this causes an issue are usually much easier to resolve.