[Python] Smettete di scrivere shell script (era: Re: Lanciare script da altro script)

[enrico franchi]

2015-03-01 9:38 GMT+00:00 Nicola Larosa <nico a teknico.net>:

> enrico franchi wrote:
> > Io sinceramente per lanciare 4 programmi in stecca scriverei 4 righe
> > di bash.
>
> Il riduzionismo degli shell script scritti "tanto sono quattro righe" è
> pernicioso.
>

Anche volere fare tutto in un dato linguaggio perche' e' "migliore" della
shell e' pernicioso.
Con questa logica ho visto aggeggi fatti in Java che funzionano male quando
sarebbero *veramente* bastate quattro righe di bash. Poi certo, in Python
e' un po' meglio.


> Non sono mai quattro righe: sappiamo bene che ogni frammento di codice ha
> la tendenza ad allungarsi, col tempo.
>

Si, boh... in generale e' cosi'. Quando sara' il momento li riscrivero' in
Python se e quando e' fattibile.


> La sintassi imbarazzante degli shell script disincentiva dallo scrivere
> codice robusto, che controlla i processi lanciati e ne gestisce i codici
> di ritorno.
>

Vero. Ora... sinceramente, bash avra' sintassi imbarazzante per varie cose.
Pero' anche tutto il visual noise che subprocess genera quando viene usato
al posto di uno shell script (ovvero, non per un caso tipico di
"subprocess", ma proprio per fare il mestiere della shell)  non e' che sia
bello.

Poi ci sono un sacco di discorsi accessori sui bachi che usare subprocess
"blindly" ti introduce. Allora, abbiamo per esempio tar che quando hai un
-z/-j sotto il cofano tira su una pipe, ma Python non ne sa nulla e a
seconda di quello che fai hai grosso modo solo una linea di errore nello
standard error. E si, si mette a posto con due calci a prefork_exec...
probabilmente quando ti capita una volta poi te lo ricordi. Il problema non
si limita a tar, e' generale. In generale, il fatto che Python debba farsi
un po' i fatti suoi con i signal handlers (per permettere un'esperienza
piu' Pythonica a chi ci scrive applicazioni) tende ad essere un problema
quando invece lo si usa come "glorified shell".
http://bugs.python.org/issue1652

Oppure il fatto che quando si usa subprocess.PIPE come output e un processo
ti genera piu' di 64K di dati ti si inchioda Python. Solo per nominare i
primi due che mi passano per la testa.

Entrambe le cose possono essere aggiustate dall'utente; ma si complica il
codice, diventa piu' brutto e soprattutto non e' per un accidenti
intuitivo. Richiede conoscenze sull'implementazione interna di subprocess
oppure dettagli non completamente diffusi fra gli sviluppatori medi su
concetti di base Unix e sul comportamento leggermente non standard che
Python ha in proposito. Ovvero, dando in mano subprocess a scatola chiusa,
si hanno un po' di bachi tutti li da scoprire.


> Disincentiva anche dallo scrivere test: avete mai visto shell script
> corredati di test, anche quelli molto lunghi? E purtroppo ce ne sono
> ancora tanti, di questi ultimi.
>

Se e' per questo ho anche visto fin troppi programmi "top level" senza
test. Va bene se le funzioni che chiamano sono testate.
Scusa, ma io non credo che lo sviluppatore che non scrive i test per un
semplice shell script magicamente li scriverebbe se quelle quattro righe di
bash diventano 10 righe di Python.

Aggiungo poi che di fatto sono anche test particolarmente pelosi da
scrivere in ogni caso. Il problema e' acchiappare quanto va mockato e
quanto no; entrambi gli approcci possono portare a test fragili, troppo
specifici e inutili. Poi spesso e volentieri bisognerebbe anche che il
processo interno supportasse di essere mockato *da fuori* per fare cose
sensate. Ovvero il problema di fare testing di questo tipo di cose e'
particolarmente incasinato di suo e lo lascerei temporaneamente fuori.

L'assenza di documentazione e commenti nella totalità degli script in
> circolazione è poi ben al di là dell'imbarazzante.
>

E allo stesso modo la stessa cosa si puo' dire per l'equivalente fatto con
altre tecnologie.


> Abbiamo uno strumento molto migliore per scrivere script, anche corti,
> anche di sistema: usiamolo.
>

Anche qui si pone un problema... e' *davvero* uno strumento "di sistema"?
Per me non lo e'.
E' qualcosa che posso installare, certo. Probabilmente quando
l'applicazione principale e' Python non mi costa troppo avere Python gia'
pronto in fase di bootstrap. Ma quando non lo e'? Non voglio dichiarare
Python come dipendenza per ogni maledetto ambiente che creo.

E ci sono ancora altri casi... chesso'... fabric. Fabric funziona bene, ma
di non mi risolve il problema di avere sugli host un env configurato a modo
(a meno di non averlo *pre* configurato). Viceversa gli equivalenti
costruiti su ssh mitigano il problema perche' tipicamente si basano su un
ambiente molto piu' semplice e standardizzato.


> E chi trovasse il codice basato su subprocess ancora troppo prolisso può
> usare quel gioiello della libreria "sh" <http://amoffat.github.io/sh/>.
>

Prima del mio arrivo avemmo parecchi problemi con suddetta libreria. Se
ripesco qualcuno dei "vecchi" chiedo meglio le specifiche.



-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150301/d2901e7f/attachment-0001.html>