Releases: dymmond/esmerald
Releases · dymmond/esmerald
Version 3.2.3
Changed
EsmeraldScheduler
integration with Asyncz is not assembled before the configuration of the routing,
allowing multiple events to be triggered without overriding.
Version 3.2.2
These changes were missed from the version 3.2.1
Changed
- Updated the default scheduler class to be in the configuration.
- Internal Dispatcher implemented for the routing and response handlers update.
Version 3.2.1
Changed
Context
is not inheriting directly from Lilya.
Fixed
- The default
scheduler_class
internal settings validation.
Version 3.2.0
Added
settings_module
also supports import as string.- New
encoders
to Esmerald settings and instance parameters. - New
register_encoder
encoder in any Esmerald and ChildEsmerald instances. - New
encoders
to Esmerald responses. This allows to use any Response as ASGI application.
with unique custom encoders. - Encoders documentation.
Changed
- Internal refactor of the
classmethods
of theTransformerModel
. The class methods
are now normal python functions. - Unifying the transformers in the signature model.
- Rename
EsmeraldSignature
toSignatureModel
.
Version 3.1.5
Added
This change was supposed to be shipped in the version 3.1.4 but it missed the release.
- Printing the stack trace when an Esmerald application is in
debug=True
providing a deeper
level of understanding the source of the errors.
Version 3.1.4
Fixed
- AsyncExitMiddleware raising exception.
- OpenAPI error when generating the parameters with dependencies.
- OpenAPI security schemes.
Version 3.1.3
Changed
- Internal support for
hatch
and removed the need for aMakefile
. - Internals for Directives. #308 by @devkral.
- Documentation references and refinements #311 by @paolodina.
WSGIMiddleware
is now pointing to Lilya.
Version 3.1.2
Fixed
- Regression with
typing_extensions
.
Version 3.1.1
Added
Changed
- Documentation improvements.
Fixed
Version 3.1.0
Added
settings_module
when passed in the instance of Esmerald will take precedence
over the global settings, removing the need of using constantly theESMERALD_SETTINGS_MODULE
.ApplicationSettingsMiddleware
as internal that handles with thesettings_module
provided and maps
the context of the settings.
Example of the way the settings are evaluated
from esmerald import Esmerald, EsmeraldAPISettings, Gateway, Include, JSONResponse, get, settings
@get()
async def home() -> JSONResponse:
return JSONResponse({"title": settings.title})
class NewSettings(EsmeraldAPISettings):
title: str = "Main app"
class NestedAppSettings(EsmeraldAPISettings):
title: str = "Nested app"
app = Esmerald(
settings_module=NewSettings,
routes=[
Gateway("/home", handler=home),
Include(
"/child",
app=Esmerald(
settings_module=NestedAppSettings,
routes=[
Gateway("/home", handler=home),
],
),
),
],
)
In the context of the controller home
, based on the path being called, it should return the
corresponding value of the title
according to the settings of the app that is included.
Changed
createapp
directiveviews.py
file generated renamed tocontrollers.py
.- Make the
EsmeraldAPISettings
hashable. - Remove
settings_config
in favor of thesettings_module
. - Bump Lilya version to 0.3.3.