Site icon Tosolini.info

Visual Studio: Debug su Odoo

Articolo obsoleto

Questo articolo risulta essere sorpassato. Si consiglia la lettura di questo post aggiornato

In realtà quanto andremo a spiegare non è specifico ad Odoo, ma può essere utilizzato in qualsiasi progetto Python. Ad ogni modo siccome lo utilizzo su Odoo farò riferimento a quest’ultimo.

Innanzitutto Visual Studio Code come sappiamo (o per chi non lo sapesse) ha un suo debugger che funziona in modo egregio fintantoché lo script in python sia direttamente eseguibile. Ovvero, per fare un esempio pratico, se il nostro file si chiama “mioscript.py” e lo lancio con il comando “python3 mioscript.py” avremo accesso diretto al codice e quindi possiamo utilizzare il debug.

Nel caso di Odoo, o qualsiasi altro programma strutturato, è quasi sicuro che stiamo lavorando a delle Add-on o delle App di quel prodotto, in questo caso il codice che abbiamo scritto viene utilizzato dal programma in questione e non ha un accesso diretto.

Ecco che si rende necessario utilizzare una sorta di proxy che ci permetta, passandogli attraverso, di vedere cosa combina il codice. Questa “cosa” è nota alla Microsoft che ha realizzato PTVSD, ovvero Python Tools for Visual Studio Debugger.

Quindi è necessario installare PTSVD come pacchetto aggiuntivo per Python, con un comando che dovrebbe essere noto, ovvero PIP3 (o PIP nel caso di Pyhton2).

pip3 install ptvsd

A questo punto abbiamo di fatto un layer (strato) che permetterebbe a Visual Studio di “vedere” cosa succede all’intero processo del codice. Per fare questo dovremo avviare sul server il programma che intendiamo debuggare come segue:

Nota: se abbiamo avviato in precedenza Odoo dobbiamo spegnerlo.

python3 -m ptvsd --host 0.0.0.0 --port 5678 /usr/bin/odoo -c /etc/odoo/odoo.conf -d miodatabase --dev=all -u mio_modulo

Vediamo un attimo di scomporre il comando. Python3 ovviamente si commenta da solo, “-m ptvsd” lancia la libreria in questione, infatti attraverso “-m” si possono eseguire script esterni. Con “–host 0.0.0.0” indichiamo che il server debba rispondere a qualsiasi host che effettua una chiamata. Su quale porta? la 5678 che per ptvsd di fatto è specie di default. Segue il comando base di Odoo, ovvero la path del suo eseguibile, con la path del file di configurazione “-c”; e il nome del database con “-d”. Opzionali “–dev=all” che di fatto auto-ricarica script ad ogni modifica, e con “-u” andiamo ad aggiornare (update) il modulo a cui stiamo lavorando e dove verosimilmente stiamo chiedendo il debug. Lanciato il comando non succederà nulla di significativo, Odoo si avvierà come di consueto.

Ora ci spostiamo sull’editor vero e proprio, qui dovremo indicare attraverso il file launch.json (da mettere nella cartella .vscode sulla root del progetto) come Visual Studio debba utilizzare il debugger. In questo caso è necessario conoscere l’indirizzo IP del server su cui gira Odoo, immaginiamo sia “10.0.0.1”, il codice di launch.json sarà:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Odoo",
            "type": "python",
            "request": "launch",
            "host" : "10.0.0.1",
            "port" : 5678,
            "program": "/usr/bin/odoo"
        }
    ]
}

Una volta salvato il file, possiamo mettere un break-point nel nostro editor di codice, per fermare l’esecuzione in un dato punto e vedere ad esempio che valori hanno assunto le variabili. Quindi avviare il debugger (tasto F5) avendo cura di scegliere “Odoo” nella lista delle possibili scelte.

Non succederà nulla, infatti il debugger è in attesa che avvenga qualcosa, ovvero dovremo andare su Odoo con il nostro browser, navigare nell’applicazione che stiamo sviluppando, eventualmente sulla pagina o funzione dove ci aspettiamo che il break-point sia raggiunto. A quel punto vedremo il debugger entrare in funzione, con i log e le varie variabili che si popolano fino allo stop sul punto che abbiamo indicato.

Conclusioni

Sostanzialmente con questa piccola “fatica” relativa all’installazione di qualcosa sul server, abbiamo a disposizione una ispezione pressoché totale dell’applicazione lato server, e quindi capire molto velocemente quale sia il malfunzionamento e quali siano le risposte “dietro le quinte” date dall’applicativo.

Exit mobile version