Architettura¶
Il pacchetto è una pipeline lineare a 4 strati: ogni livello dipende solo dai precedenti e ha responsabilità nette. Riutilizzare le primitive esistenti invece di reinventarle è la regola principale di questo progetto.
instances.json + .env
│
▼
config.py (load_instances → InstanceConfig)
│
▼
client.py (OdooClient: auth per versione)
│
▼
manager.py (ConnectionManager: cache + iterazione)
│
▼
tasks.py / excel.py (estrazione e rendering specifici)
│
▼
cli.py (sottocomandi argparse)
Strato 1 — Configurazione (config.py)¶
- Legge
instances.json(versionato) e.env(non versionato). - Valida lo schema con pydantic, applicando le regole per versione Odoo:
- v16/17 → richiedono
username+password_env. - v18/19 → richiedono
api_key_envoppureusername+password_env. - Risolve i secret dalle variabili d'ambiente.
- API pubblica:
load_instances()→list[InstanceConfig].
Strato 2 — Client RPC (client.py)¶
- Unico punto del pacchetto che istanzia
odooly.Client. - Gestisce l'autenticazione version-aware (v19 usa Bearer token, v18 passa l'API key come password, v16/17 usano user/password classici).
- Espone
connect(),health_check(), e supporta il context manager.
Anti-pattern: non istanziare
odooly.Clientdirettamente nel resto del codice. Passare sempre daOdooClient.
Strato 3 — Orchestrazione (manager.py)¶
ConnectionManagercarica tutte le istanze configurate e mantiene una cachename → OdooClient.- È il punto di ingresso raccomandato per CLI, notebook e batch.
Strato 4 — Domain helpers e CLI¶
tasks.py— query canonica perproject.task(riutilizzabile).excel.py— rendering.xlsxper i task aperti.cli.py— comandicheck,tasks,tasks-excel. Ogni nuovo comando segue lo stesso pattern: funzione_cmd_*+add_parserin_build_parser.
Eccezioni¶
Tutto il pacchetto solleva sottoclassi di OdooAnalysisError (vedi
exceptions.py). I caller possono gestire ogni errore "atteso" con un solo
except OdooAnalysisError.