ashka
ashka extends reagento/dishka with async/sync application lifecycle support.
The a prefix lets ashka sort before dishka, helping ensure the correct
import order.
Application Lifecycle
This feature requires the ashka[lifecycle] extra.
Declare the resources that must be ready before the application starts doing work. Ashka initializes them with the application. During runtime, they follow dishka's APP-scope behavior. When the container closes, dishka closes generator-based resources:
from collections.abc import AsyncIterator
import ashka
from ashka import AshkaScope, async_lifespan, provide
from dishka import Provider, make_async_container
from fastapi import FastAPI
class Database:
async def connect(self) -> None: ...
async def close(self) -> None: ...
class ApplicationProvider(Provider):
@provide(scope=AshkaScope.BOOTSTRAP)
async def database(self) -> AsyncIterator[Database]:
database = Database()
await database.connect()
yield database
await database.close()
app = FastAPI(lifespan=async_lifespan)
container = make_async_container(ApplicationProvider())
ashka.integrations.setup_dishka(container, app)
- Startup: Bootstrap dependencies are initialized before the application starts doing work.
- Runtime: Dependencies retain dishka's APP-scope caching and dependency behavior.
- Shutdown: Dishka closes generator-based resources with the container.
Independent asynchronous Bootstrap dependencies initialize concurrently. When initialization order matters, express it through provider parameters.
Container Access
This feature is available in the base ashka package and does not require the
lifecycle extra.
Attach a container through the central integration entry point, then retrieve the same container wherever the framework object is available:
import ashka
from dishka import make_async_container
from fastapi import FastAPI
app = FastAPI()
container = make_async_container()
ashka.integrations.setup_dishka(container, app)
assert ashka.integrations.get_container(app) is container
The central entry points dispatch to the corresponding integration from the runtime type of the framework object.
Documentation
1 maintainer
Metadata
1 maintainer
Release files for ashka 1.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| ashka-1.0.0.tar.gz | 7.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| ashka-1.0.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 22.9 kB
Release files / ashka-1.0.0.tar.gz
| Download URL | ashka-1.0.0.tar.gz |
|---|---|
| Size | 7.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
58c962486628b19ca61a2cbc84a5e93beaa219e1c8fa822b5d769ce052e3aa14
|
|
BLAKE2b-256 checksum How to use checksums |
f856e8417283539097f6344586b3a58e76bd930227d4eeca8365e255fe262710
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.
Transparency logRelease files / ashka-1.0.0-py3-none-any.whl
| Download URL | ashka-1.0.0-py3-none-any.whl |
|---|---|
| Size | 15.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
dca498536496eefd444cff67f5377d077a05c459b764dec4f77306da63551a1a
|
|
BLAKE2b-256 checksum How to use checksums |
c2c7d7b69c0865828bacba1fb3a4e78e9a0a05e2ebbf930c8896a0a3b290324a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.
Transparency log
