Personal tools
Integrare la validazione pyflakes in zest.releaser

Lo Zen Python: raggiungere il codice perfetto!

Apr 24, 2014

Integrare la validazione pyflakes in zest.releaser

Ci sono molti strumenti di validazione del codice Python. Vediamo come integrare uno di questi (pyflakes) all'interno del nostro processo di rilascio

Tempo fa avevo mostrato tutti i modi con cui è possibile gestire i rilasci del vostro codice Plone/Python, terminando l'articolo con un plugin per zest.releaser, uno degli strumenti che più utilizziamo.

Di quanto zest.releaser sia utile, ben pensato ed estendibile, ne ho già parlato a sufficienza nel precedente articolo e non voglio ripetermi.
Oggi andiamo avanti nel processo di rendere il vostro codice migliore, introducendo un altro plugin: rt.zestreleaser.pyflakes.

Pyflakes (e cugini)

Cos'è pyflakes?
Nella comunità Python, pyflakes è uno strumento ben noto che si autodefinisce come un "passive checker of Python programs".

Nella pratica: analizza il vostro sorgente Python in modo passivo (non lo esegue) alla ricerca di errori logici e possibili migliorie. Alcuni esempi:

  • importazioni di moduli esterni, poi mai utilizzati
  • assegnazione di variabili non usate
  • uso di nomi non definiti
  • ...

C'è una grossa differenza tra questo strumento e altri analizzatori passivi come PEP8 e derivati: i tool di validazione alla PEP8 analizzano lo stile del vostro codice in conformità con la Python Enhancement Proposals numero 8, ovvero analizzando lo stile con cui avete scritto il vostro codice (controllo di dove e come avete inserito spazi o righe vuote, numero di caratteri per riga, ...).
Pyflakes, invece, non giudica il vostro stile di programmazione ma in alcuni casi (e capita più spesso di quanto crediate, soprattutto se non avete l'abitudine di testate il vostro codice) permette di scovare bug.

Commit hook

Verrebbe da chiedersi: pyflakes e PEP8 potrebbero quindi essere integrati come commit hook nel vostro sistema di versionamento del codice?

Per chi non conoscesse i commit hook: sono sistemi che analizzano il vostro codice al momento dell'invio al sistema di versionamento e lo rifiutano in base ad alcune regole.

Da parte mia, non sono un grande amante dello stile definito nella PEP8 (almeno non di tutte le sue parti), ma in effetti un'azienda potrebbe decidere di aggiungere un pre-commit-hook e obbligare, quindi, tutti i propri programmatori a seguire lo stile definito. Questo modo di fare obbliga tutti i membri del team di sviluppo a uniformarsi a uno stile di programmazione e ci sono di certo alcuni benefici, tra cui rendere il codice di un aspetto familiare a tutti.

Vale lo stesso per pyflakes?

Qui in RedTurtle, qualche anno fa, avevamo attivato su alcuni repository un pre-commit-hook che validava il codice usando pyflakes, ma la cosa mi ha sempre provocato qualche "mal di testa".

Pyflakes offre validi suggerimenti, e tutti dovrebbero usarlo (molti IDE di sviluppo Python lo hanno integrato nativamente), ma a mio parere lo sviluppatore deve essere libero di ignorarli.
Per fare un esempio: la pulizia di direttive import inutilizzate è un'ottima cosa finché questo vi corregge una dimenticanza, ma a volte capita che quello che volevate fare era semplicemente importare (quindi eseguire) un modulo.

Un altro caso: state importando un codice di terze parti nel vostro repository, magari per farne una versione personalizzata, e trovate migliaia di errori... reagireste bene?!

Avere una stringente esecuzione di un pre-commit-hook con pyflakes attivo si traduce molto spesso in un codice più brutto, aggiungendovi righe atte ad imbrogliare il validatore stesso:

import modulo_esterno
modulo_esterno

Nell'esempio sopra, oltre ad importare un modulo, lo stiamo nei fatti "usando" (seppur questa operazione non comporti nulla). Pyflakes è contento e ci permette di proseguire... ma che cosa ci abbiamo guadagnato?

Validare il proprio codice

Come avrete capito, la soluzione che consiglio è quella di eseguire pyflakes in autonomia o averlo disponibile nel proprio ambiente di sviluppo.
Mi rendo anche conto che l'esecuzione del comando "pyflakes" prima di ogni release ufficiale è qualcosa di facilmente dimenticabile... allora perché non farlo fare a zest.releaser?

Da qui nasce l'idea di questo nuovo plugin, che inserisce la validazione pyflakes all'interno del processo di release:

$ fullrelease
INFO: Starting prerelease.
Enter version [0.2.1]:
INFO: History file docs/HISTORY.txt updated.
INFO: The 'git diff':

diff --git a/docs/HISTORY.txt b/docs/HISTORY.txt
index e7c1dc0..4da78c0 100644
--- a/docs/HISTORY.txt
+++ b/docs/HISTORY.txt
@@ -1,7 +1,7 @@
Changelog
=========

-0.2.1 (unreleased)
+0.2.1 (2014-04-18)
------------------

- Initial release


OK to commit this (Y/n)?
INFO: [master 3c8c717] Preparing release 0.2.1
1 file changed, 1 insertion(+), 1 deletion(-)

A questo punto interviene il nostro nuovo plugin:

You have Pyflakes warning. Do you want to see them? (Y/n)?

/private/tmp/aaa.bbb/aaa/bbb/__init__.py:3: 'patches' imported but unused

Do you want to continue anyway? (y/N)?

Il suo funzionamento si traduce in due domande.
La prima avverte del fatto che pyflakes ha trovato potenziali problemi nel vostro codice e chiede conferma per vedere l'output. Questa domanda permette di saltare l'output pyflakes nel caso in cui siate ben consci che ci sono errori e non volete vederli ogni volta.

Nel caso (predefinito) in cui vogliate controllare, viene mostrato l'output e vi viene chiesto se procedere comunque.
Di solito lo sviluppatore risponderà "No" per fermarsi e sistemare il proprio codice. Al lancio successivo del comando di release, se tutti gli errori sono stati sistemati, l'analisi pyflakes non presenterà nulla.

Conclusione

Se anche voi usate con soddisfazione zest.releaser, valutate l'installazione di questo plugin e iniziate così a generare codice migliore!

Alla prossima!

Filed under: ,
comments powered by Disqus