mic-core
Fondations agnostiques du framework MIC (Model / Interface / Controller).
mic-core est le socle : il ne dépend d'aucune brique de persistance ni de
plateforme (voir le DAG platform → data → core dans
../README.md).
Modules
| Module | Rôle |
|---|---|
mic.contracts |
Contrats / DTO partagés inter-couches |
mic.model |
Erreurs de domaine (DomainError, TransientError), value objects |
mic.http |
Spécifications HTTP agnostiques (HttpRouteSpec, HttpResponseSpec, HttpCookieSpec, HttpRequestContext) |
mic.fastapi |
Adaptateur FastAPI (router builder, middlewares) — extra [fastapi] |
mic.litestar |
Adaptateur Litestar — extra [litestar] |
mic.auth |
JWT service-to-service [auth] et vérification OIDC/JWKS [oidc] |
mic.client |
Client HTTP inter-services (httpx) — extra [client] |
mic.observability |
Logs JSON, métriques Prometheus, traces OTel — extra [observability] / [full-observability] |
mic.healthcheck |
Sondes liveness/readiness |
mic.resilience |
Circuit breaker, retry, timeouts |
mic.cli |
Squelette CLI (argparse stdlib) — extra [cli] |
mic.grpc |
Transport gRPC — extra [grpc] |
mic.event_replay |
Replay d'events archivés vers un bus (CLI mic-events-replay) |
Le paquet est un namespace PEP 420 (pas de mic/__init__.py) : import mic.*
reste identique côté consommateur, qu'on installe mic-core seul ou avec
mic-datastore / mic-platform.
Replay d'events (mic-events-replay)
Rejoue des events archivés (DLQ outbox exportée en JSON, ou archive ClickHouse long-terme) vers un sink. Cas d'usage : audit forensic, bug-fix rétroactif (un handler a swallow des events pendant N heures → on les rejoue après fix), amorçage d'un nouveau read-model depuis l'historique.
# Dry-run (compte uniquement) depuis un dump JSON
mic-events-replay --from-json dump.json \
--topic mail.send --from 2026-06-22T08:00:00Z --to 2026-06-22T10:00:00Z
# Source ClickHouse + filtre payload (répétable)
mic-events-replay --from-clickhouse http://clickhouse.svc:8123 \
--topic mail.send --from 2026-06-22T08:00:00Z --to 2026-06-22T10:00:00Z \
--filter to_email=user@example.com
# Sink NATS JetStream (republie avec header x-replay) — extra mic-datastore[nats]
mic-events-replay --from-clickhouse http://clickhouse.svc:8123 \
--topic mail.send --from ... --to ... \
--to-nats nats://nats-0:4222,nats://nats-1:4222 --nats-stream events
Sinks : aucun = dry-run ; --target module:callable = callback sync ;
--to-nats = NATS JetStream. Exit 0 = OK, 1 = aucun event matché
(topic/range mal pinnés ?), 2 = erreur de setup.
Convention header x-replay
Chaque event republié via --to-nats porte deux headers transport
(le payload n'est pas réécrit — flag transparent) :
| Header | Valeur |
|---|---|
x-replay |
true |
x-replay-batch-id |
UUID unique par invocation (corrélation / traçabilité) |
⚠️ Les consumers doivent être idempotents — un replay redélivre des events
déjà traités. Un consumer idempotent (clé dérivée de event_id / original_id,
ou opérations naturellement idempotentes) absorbe les replays sans effet de
bord ; le header x-replay lui permet en plus de tracer ou ignorer
explicitement un replay sans changer son décodage de payload. Le support des
headers est fourni par mic.queue (cf. mic-datastore).
Installation
pip install "mic-core[fastapi,auth,client,observability]"
Jetons de service à portée limitée
ServiceAuthSigner.sign(scopes=[...]) encode le claim JWT standard scope.
ServiceAuthVerifier.verify() expose les valeurs dans claims.scopes, tandis
que require(token, scope=...) exige une correspondance exacte et renvoie une
erreur 403 service_auth.insufficient_scope si le service authentifié n'a pas
la permission demandée. Les tokens historiques sans scope restent valides pour
verify() ; les opérations protégées doivent appeler explicitement
require().
Extras
| Extra | Tire |
|---|---|
fastapi |
fastapi + uvicorn[standard] + starlette |
litestar |
litestar |
auth |
pyjwt |
oidc |
pyjwt + cryptography |
client |
httpx |
observability |
prometheus-client + opentelemetry-api |
sentry |
sentry-sdk (+ urllib3 patché) |
tracing |
opentelemetry-sdk + exporter OTLP |
full-observability |
observability + sentry + tracing |
grpc |
grpcio + grpcio-health-checking |
cli |
(rien — argparse stdlib) |
Versionnage
mic-core démarre en 0.x (pré-releases dev/rc sur TestPyPI). Il graduera
en 1.0 une fois les frontières prouvées et les services migrés (fin du split,
cf. ADR-0001).
En 0.x, un bump minor peut porter un changement cassant (SemVer 0.x) —
contraindre avec >=0.1,<1.
Release
Voir ../../RELEASING.md § « Release par paquet »
(make release-pkg PKG=core VERSION=x.y.z → tag core-vX.Y.Z).
1 maintainer
Metadata
1 maintainer
Release files for mic-core 0.1.27
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| mic_core-0.1.27.tar.gz | 125.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mic_core-0.1.27-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 290.0 kB
Release files / mic_core-0.1.27.tar.gz
| Download URL | mic_core-0.1.27.tar.gz |
|---|---|
| Size | 125.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
bdcec48347fb8c7ad810b89f993a02bbfe184755521b5e2f1ccd2744ee4fed0a
|
|
BLAKE2b-256 checksum How to use checksums |
afb262e7ae97ffab9da8acd2855212d68740646955ae3a47d4d035be85f5bfc8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|
Release files / mic_core-0.1.27-py3-none-any.whl
| Download URL | mic_core-0.1.27-py3-none-any.whl |
|---|---|
| Size | 164.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e1652ffc6b1ffa124b1401ad190636a2089c9a87e116cb593cddecb1e73ee6f7
|
|
BLAKE2b-256 checksum How to use checksums |
9a822fedd7f1303c3705b6f85ec39cfed39cc609e2a06806f6b3319d04576627
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|
Security for mic-core 0.1.27
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.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
