(by Ivan Tarozzi - 10/06/2021)
Prendendo spunto da uno scambio di messaggi telegram sul gruppo FabLab Romagna (SMD 2023) e nella speranza che possa essere utile a chiunque voglia cimentarsi nella programmazione python su raspberryPI (o anche solo a chi voglia testare programmi python presi su git**b), riporto alcune indicazioni e considerazioni sull'esperienza appena conclusa e su modi alternativi di affrontare il problema.
Premetto che non sono un super-esperto di python e che le considerazioni che scriverò sono personali e perfettamente opinabili. Sono frutto della mia esperienza, ma non è detto che siano valide per tutti e che non possano essere smentite (anzi, chiunque legga e voglia apportare critiche costruttive o contributi diversi ben venga).
Il tutto è partito dal tentativo di utilizzare un programma presente su github da parte di Maurizio: https://github.com/danclarke/WorkingStargateMk2Raspi
L'obiettivo era installare e testare il sw su una raspOS lite, quindi priva di parte grafica.
Il sw in oggetto, scritto per python2, utilzza una serie di librerie Adafruit per l'accesso tramite GPIO ad una serie di sensori ed attuatori. Si veda il readme file per i dettagli.
L'ultimo commit del progetto risale a maggio 2018.
Il progetto fa uso di Python2 (oramai non più supportato) e ha una serie di dipendenze importanti (tra cui pygame).
Il file readme descrive la procedura di installazione con le relative dipendenze, ma evidentemente non contempla alcune variazioni dovute ai 3 anni passati e all'evoluazione della raspbian e relativi moduli python.
Seguendo le istruzioni del readme Maurizio ha dapprima installato i pacchetti richiesti via apt, e poi ha installato via pip (il package manager python) i moduli Adafruit, gpiozero e pygame. E su quest'ultimo ci sono stati i primi problemi. Non ho mai usato personalmente quel modulo, ma appoggiandosi a SDL e appoggiandosi pesantemente ad alcune librerie multimediali di sistema, in fase di installazione con pip tenta di compilare una serie di cose per cui, se le dipendenze non sono tutte soddisfatte, non funziona.
La soluzione più semplice è stata quella di utilizzare il modulo pygame installandolo da repository debian con apt, invece che installarlo con pip (sudo apt install python-pygame ) - si veda paragrafo successivo.
Il secondo errore rilevato riguardava un import di un modulo chiamato Daemon, che non risultava disponibile ed elencato nelle dipedenze.
In questo caso è stato sufficiente installare il modulo via pip sudo pip install python-daemon e poi modificare nel main.py l'istruzione di import, usando il nome del modulo in minuscolo. Forse nel corso degli anni quel modulo ha subito unn refactory.
Situazione simile con il modulo smbus, non descritto nel readme, che è stato installato con sudo pip install smbus
Alcuni errori a runtime finali dipendevano poi dalla mancata abiltiazione del bus I2C (da eseguire tramite utility di configurazione del raspberryPI) e della mancanza dell'HW fisico collegato. Una volta sistemati anche questi aspetti tutto è partito senza problemi.
Nel caso si voglia installare i moduli python tramite pip, o si verifichi un errore di import per mancanza di un modulo sul proprio sistema, la cosa più semplice è cercare il modulo sul sito del package manager (https://pypi.org) . In questo modo verrà descritto il comando pip da utilizzare per l'installazione e (se il programmatore ha fatto un buon lavoro di documentazione) verranno mostrati alcuni esempi di utilizzo.
La ricerca diretta del modulo tramite utility pip non è più funzionante.
Ove possibile, se si parte con un proprio progetto, usare python3! Questo sia per utilizzare un linguaggio più maturo e supportato, ma anche perchè molti dei moduli di terze parti (presenti in pypi.org) diventeranno col tempo non più supportati in python2, a maggior ragione se legati molto alle librerie di sistema.
Ovviamente, se si sta tentando di utilizzare un progetto già pronto scritto in python2, occorre provare a farlo funzionare superando eventuali difficoltà dovute molte volte anche solo a documentazione non aggiornata.
Sui recenti sistemi debian derivati (ma anche su altre distribuzioni Linux) esiste la doppia possibilità per installare un modulo python :
- tramite pip (attingendo a pypi.org)
- tramite apt (da repository della distribuzione)
Usare una o l'altra modalità dipende a volte da preferenze personali, e altre volte da casi di uso del progetto. Ci sono decine di articoli/tutorial sul web, quindi ognuno si faccia la sua idea.
In generale la mia attuale idea è la seguente:
- se devo installare un'app di sistema di solito uso apt per eventuali moduli mancanti, ma solitamente ci pensa apt quando installo anche l'app da repository.
- se scarico un'app da git**b o se parto con un progetto mio, utilizzo pip ma di solito non installo mai i moduli nel mio profilo utente o a livello di sistema. Utilizzo invece virtualenv in modo da creare ambienti dedicati senza intaccare i moduli di sistema.
Occorre usare virtualenv con moderazione e capire quando abbia senso crearne uno nuovo o utilizzarne uno già presente. In generale io ne utilizzo uno generico per i programmi che scarico e che penso vorrò continuare ad utilizzare nel tempo.
A meno che il programma in oggetto non sia molto poco maturo o in sviuppo molto veloce; in quel caso virtualenv separato.
Per test veloci o programmi personali solitamente uso virtualenv dedicati, che nascono e muoiono con la presenza sul disco del progetto che li usa.
Forse si è capito, sono un fan di virtualenv e lo uso più che posso, visto che nel tempo mi ha evitato diverse grane. C'è però un ambito in cui invece utilizzo apt, ed è il caso del raspberryPI.
A maggior ragione se il progetto fa uso di moduli che si interfacciano con l'HW di sistema, come nel caso di pyGame, ma anche pyserial, pyside2/6 ecc.
In passato ho avuto grandi difficoltà ad insallare alcuni moduli all'interno di virtualenv, e mi sono fatto l'idea che alcune procedure di setup (usate da pip in fase di installazione) non supportino perfettamente la controparte ARM.
Quindi, generalmente faccio un tentativo per usare virtualenv anche sul raspberryPI, ma se incontro difficoltà o se vedo che vengono usati moduli particolari, allora uso direttamente apt.
Idem se il raspberryPI viene utilizzato come dispositivo embedded "mono-applicazione". In quel caso installo tutto il possibile tramite apt.
L'utilizzo di docker per la creazione di ambienti python circoscritti e replicabili sono una terza opzione, se vogliamo una "evoluzione" di virtualenv. La cosa però non è immediata e banale e richiede comunque conoscenze aggiuntive per crearsi un ambiente idoneo attraverso docker. Inoltre nel caso di sistemi embedded e/o che fanno uso di HW di sistema, si rischia di incorrere nelle stesse problematiche di virtualenv.
Programmare in python può essere un'esperienza frustrante o appagante come in ogni linguaggio.
Sicuramente chi si trova di fronte a certi problemi la prima volta e senza tanta esperienza, rischia di perdere molto più tempo del necessario, ma questo accade ovunque.
Imparare un nuovo linguaggio è solo una parte (minimale?) del problema, perchè a volte, anche solo da utilizzatore, il grosso dei problemi riguardano l'ecosistema completo, e quindi le librerie, i package manager, la gestione delle dipedenze.
Un buon progetto ha spesso (ma non sempre) una buona documentazione, soprattutto aggiornata; e molte volte un copia-incolla dal readme al terminale funziona al primo colpo. Purtroppo tutto evolve in fretta, e chi programma spesso non dedica il tempo giusto alla documentazione. Quindi tra readme obsoleti o sistemi operativi che cambiano in fretta, spesso occorre una certa dose di esperienza per venire a capo di certe problematiche.
Nel caso del progetto in oggetto, soprattutto considerando il target raspberryPI, non avrei avuto grossi dubbi nell'installare tutto tramite apt, ma come visto sopra alcuni aggiustamenti sarebbero comunque stati richiesti.
.... alla fine il risultato l'abbiamo portato a casa!