[Python] Dizionario modificato.
Prendiamo questo semplice codice:
def list():
elem = dict()
lista = []
for x in range(3):
elem['nome'] = x
lista.append(elem)
print lista
list()
Mi aspetterei come output:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]
Quello che ottengo è invece:
[{'nome': 2}, {'nome': 2}, {'nome': 2}]
Se invece il ciclo lo scrivo così (elem lo dichiaro dentro il ciclo):
def list():
lista = []
for x in range(3):
elem = dict()
elem['nome'] = x
lista.append(elem)
print lista
list()
ottengo l'output come previsto.
Cosa succede nel primo caso?
Viene modificato il dizionario messo nella lista?
Perché?
Grazie
Walter
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
Nel primo caso viene creata una lista i cui elementi sono riferimenti allo
(e non copie dello) stesso oggetto, mentre nel secondo caso memorizzi tre
riferimenti a tre oggetti dict distinti che vivono di vita propria.
Il giorno 05 settembre 2014 10:18, Walter Valenti waltervale...@yahoo.it
ha scritto:
Prendiamo questo semplice codice:
def list():
elem = dict()
lista = []
for x in range(3):
elem['nome'] = x
lista.append(elem)
print lista
list()
Mi aspetterei come output:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]
Quello che ottengo è invece:
[{'nome': 2}, {'nome': 2}, {'nome': 2}]
Se invece il ciclo lo scrivo così (elem lo dichiaro dentro il ciclo):
def list():
lista = []
for x in range(3):
elem = dict()
elem['nome'] = x
lista.append(elem)
print lista
list()
ottengo l'output come previsto.
Cosa succede nel primo caso?
Viene modificato il dizionario messo nella lista?
Perché?
Grazie
Walter
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
--
Shipping is a feature. A really important feature. Your product must have
it.
Rendete ogni cosa il più semplice possibile, ma non di più (Albert
Einstein)
You are what you choose today, not what you've chosen before
Unix IS user friendly. It's just selective about who its friend are
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
Walter Valenti: Cosa succede nel primo caso? Viene modificato il dizionario messo nella lista? Perché? Si, nel primo caso si modifica il dizionario. Perché nel primo caso c'è una sola creazione dict() mentre nel secondo ci sono tre creazioni, una per ciclo. Quindi nella lista finale nel primo caso hai aggiunto 3 volte lo stesso dizionario, che ha quindi un solo valore aggiornato dall'ultimo ciclo. Nel secondo caso ci sono 3 dizionari ognuno con un valore diverso. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
On 05/09/2014 10:18, Walter Valenti wrote:
Prendiamo questo semplice codice:
def list():
elem = dict()
lista = []
for x in range(3):
elem['nome'] = x
lista.append(elem)
print lista
list()
Mi aspetterei come output:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]
Quello che ottengo è invece:
[{'nome': 2}, {'nome': 2}, {'nome': 2}]
Oltre alle risposte già data forse potrebbe essere d'interesse questa
discussione su Stackoverflow:
http://stackoverflow.com/questions/3611760/scoping-in-python-for-loops
Lorenzo.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] socket e MSG_OOB: bug?
2014-09-04 12:19 GMT+02:00 Remo The Last py.remothel...@yahoo.it: Buongiorno lista. Continuando la mia programmazione relativa all'invio di segnali hex, ho potuto confermare quanto letto in linea che un server python con flag MSG_OOB Perchè mai usi MSG_OOB, ossia messaggi fuori banda, la cui semantica è implementation specific? http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/recv.html crasha sempre. E questa è una conferma. Cosa intendi con crasha? Per me (e per molti altri) crashare significa andare in segfault, ma dubito che sia questo il caso. Probabilmente intendi che viene sollevata una eccezione, che dovrebbe darti utili informazioni aggiuntive. Ma è anche vero che un socket client con flag MSG_OOB taglia a destra di un byte il messaggio da inviare. Come saprai, se fai un send(N bytes) e recv(N bytes) non è detto che recv ti restituisca esattamente N bytes, ma di solito qualcosa in meno. Il tutto poi è complicato dall'uso dei messaggi out-of-band. Che tipo di socket stai usando? Che sistema operativo? L'ho potuto appurare sia in locale con una semplice applicazione client-server ma anche su un mio server remoto. In intrambi i casi il messaggio è risultato tagliato a destra di una byte. Tipo: msg=hello world e arriva hello worl. Per ovviare allungo di un byte il messaggio e questo arriva completo come messaggio da invio originale. Questo è un errore molto comune tra chi si avvicina alla programmazione di rete. Quando invii qualcosa via socket di tipo stream devi **sempre** usare un protocollo che permetta a chi riceve i dati di capire dove inizia e dove finisce un messaggio. In particolare, se vuoi spedire messaggi brevi in modo facile, usa i socket di tipo SOCK_DGRAM invece di SOCK_STREAM, ma assicurati di capire come funzionano. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] combinazione tasti in hex
2014-08-27 22:13 GMT+02:00 Remo The Last py.remothel...@yahoo.it: ciao lista, sto implementando un programmino che invia a remoto una combinazione di tasti: ex ctrl-Z, ctrl-C (ecc) utilizzando il suo corrispettivo in hex. Dato che dubito siano combinazioni di tasti arbitrarie, ma semplicemente combinazione di tasti per ottenere caratteri speciali, perchè non invii semplicemente il codice Unicode (codificato in UTF-8) del carattere speciale? In realtà i caratteri di controllo standard sono a 7 bit (US-ASCII). Vedi: http://en.wikipedia.org/wiki/Control_character http://en.wikipedia.org/wiki/C0_and_C1_control_codes http://www.keller.com/html-quickref/latin1.html L'ultima è forse quella che ti serve, ma tieni conto che non è standard. [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
Lorenzo Sutton: Oltre alle risposte già data forse potrebbe essere d'interesse questa discussione su Stackoverflow: http://stackoverflow.com/questions/3611760/scoping-in-python-for-loops non risponde alla domanda... però confermo è interessante :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
Cosa succede nel primo caso?
Viene modificato il dizionario messo nella lista?
Perché?
Nel primo caso ogni iterazione del ciclo for modifica lo stesso oggetto
elem, definito fuori dal ciclo e aggiunto più volte alla lista. Quando
viene inserito l'oggetto nella lista non viene ridefinito, come nel secondo
esempio.
Questo codice, ulteriormente semplificato eliminando il for, forse si
capisce meglio:
elem = dict()
lista = []
elem['nome'] = 0
lista.append(elem)
elem['nome'] = 1
lista.append(elem)
print lista
L'output è:
[{'nome': 1}, {'nome': 1}]
Se invece scrivo:
lista = []
elem = dict()
elem['nome'] = 0
lista.append(elem)
elem = dict()
elem['nome'] = 1
lista.append(elem)
print lista
elem viene ridefinito prima del secondo inserimento e infatti l'output è:
[{'nome': 0}, {'nome': 1}]
Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] combinazione tasti in hex
2014-09-05 12:37 GMT+02:00 Manlio Perillo manlio.peri...@gmail.com: 2014-08-27 22:13 GMT+02:00 Remo The Last py.remothel...@yahoo.it: ciao lista, sto implementando un programmino che invia a remoto una combinazione di tasti: ex ctrl-Z, ctrl-C (ecc) utilizzando il suo corrispettivo in hex. Dato che dubito siano combinazioni di tasti arbitrarie, ma semplicemente combinazione di tasti per ottenere caratteri speciali, perchè non invii semplicemente il codice Unicode (codificato in UTF-8) del carattere speciale? Ecco uno script che stampa a schermo i caratteri Unicode associati ai tasti (o combinazione di tasti) premuti. L'ho chiamato showchars, ed è simile a showkeys di Linux ma più di alto livello dato che tratta caratteri e non codici della tastiera: http://pastebin.com/VHSTF2Je Il codice è per Python 2.x [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Dizionario modificato.
Il giorno 05 settembre 2014 10:18, Walter Valenti waltervale...@yahoo.it
ha scritto:
Prendiamo questo semplice codice:
def list():
elem = dict()
lista = []
for x in range(3):
elem['nome'] = x
lista.append(elem)
print lista
list()
Mi aspetterei come output:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]
Quello che ottengo è invece:
[{'nome': 2}, {'nome': 2}, {'nome': 2}]
imho quello che ti spiazza è il comportamento dell'append(), perchè ti
aspetti che all'interno del ciclo for,
l'append gestisca il *valore*, mentre in realta' gestisce le referenze. Mi
spiego meglio: quando usi l'append() tu
non fai altro che prendere una referenza al valore di elem ed assegnarla in
coda alla list lista.
Facendo in questo modo, ad ogni ciclo, al sovrascrivere del valore di elem,
variano tutte le sue referenze,
ed è per questo motivo che -a fine ciclo- ti ritrovi [{'nome': 2}, {'nome':
2}, {'nome': 2}], cioè il valore *finale* di elem, cui puntano
tutte le referenze appese in precedenza.
A tal proposito, guarda il comportamento del seguente codice:
def list():
elem = dict()
lista = []
for x in range(3):
elem['nome'] = x
copia_shallow = elem.copy()
lista.append(copia_shallow)
print(lista)
list()
risultato:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]
ciao
Alberto De Prezzo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
2014-09-04 23:49 GMT+01:00 Balan Victor balan.vict...@gmail.com: Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non lo hai provato, ho seri dubbi in proposito. provato con 2.7 e 3.4 Allora, il pacchetto autocontenuto e' molto piu' tipico del mondo windows che del mondo unix. Parliamoci... e' un pacchetto che hai scritto e vuoi distribuire o e' un pacchetto che devi deployare su suddette macchine *di persona*? deployare su server *di persona*, almeno al primo giro. Dal secondo giro in avanti il programma è in grado di auto-aggiornarsi. Il programma non gira su server dedicati quindi non posso pensare di usare roba tipo docker e non voglio nemmeno dipendere dal python installato di default sul sistema. Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... Sono anche nervosetto all'idea dell'auto-aggiornamento. Specie perche' dubito che faccia tutto quello che deve (e.g., avere metriche che allarmano e fanno rollback della nuova versione in automatico... genericamente un sistema del genere ha bisogno di un po' di infrastruttura non banale che se avessi probabilmente risolverebbe anche il problema del deploy). Non dipendere dal python di default e' ovviamente saggio. Boh... se non avessi windows fra le scatole ti suggerirei veramente qualcosa di chef/puppet based che si succhia in qualche modo il python (eventualmente compilandoselo) e poi fa tutto quanto il resto. Non ho idea di come fare su windows. Te lo ho gia' detto che con windows non ci tratto? ;) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... si lo so. Chef non lo conoscevo, adesso mi sto guardano un po di documentazione Sono anche nervosetto all'idea dell'auto-aggiornamento. Specie perche' dubito che faccia tutto quello che deve (e.g., avere metriche che allarmano e fanno rollback della nuova versione in automatico... genericamente un sistema del genere ha bisogno di un po' di infrastruttura non banale che se avessi probabilmente risolverebbe anche il problema del deploy). L'infrastruttura c'è già. Il programma in fase di starup si connette a un server dedicato che fa da repository/configurator da cui scarica la configurazione da usare, nella configurazione è contenuta anche la versione del sorgente. Una volta che il programma ha la configurazione confronta la versione sul repository con quella locale e se non corrispondono scarica il nuovo sorgente lo sostituisce con quello attuale e poi si auto-restarta. Quindi il problema di aggiornare gli sorgenti non c'è l'ho. Ho il problema di aggiornare python. Avevo pensato di fare in pasto anche la gestione della versione di python al programma però mi troverei di fronte a compilazioni di sorgenti su mondo linux/unix e silent installer su mondo windows ... Non dipendere dal python di default e' ovviamente saggio. Boh... se non avessi windows fra le scatole ti suggerirei veramente qualcosa di chef/puppet based che si succhia in qualche modo il python (eventualmente compilandoselo) e poi fa tutto quanto il resto. Non ho idea di come fare su windows. Te lo ho gia' detto che con windows non ci tratto? ;) come scritto sopra mi sto studiando un po chef per quello che riguarda windows avevo pensato anche a qualcosa come portable python, ma non sono molto convinto. -- Balan Victor ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-05 18:14, Balan Victor wrote: Uhm... poi ovviamente docker non e' che gira su tutta la roba che hai descritto. Chef pero' potresti usarlo... si lo so. Chef non lo conoscevo, adesso mi sto guardano un po di documentazione Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi: - non serve un server sulla macchina remota: basta ssh per usarlo - non serve conoscere ruby per usarlo (non serve neanche conoscere Python per usarlo, basta yaml; per Chef invece devi scrivere roba Ruby) - se ti serve hackarlo, e' scritto in Python, che si suppone tu conosca. Io ci ho passato le ultime due settimane e sono state positive. Ci ho fatto in breve tempo cose piuttosto complesse, per risolvere alcuni problemi mi sono scritto un modulo di estensione mio (e un altro l'ho cherry-pickato dalla prossima versione ancora da rilasciare). Ho mandato patch upstream e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in pochi giorni! Come detto sopra non serve essere uno sviluppatore per usarlo perche' hai solo da scrivere file umani con la descrizione dei passi da fare. Se poi dovesse essere necessario mettere le mani dentro al motore, meglio Python che Ruby (tra l'altro e' scritto in maniera abbastanza semplice). -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-05 19:04, Francesco Pischedda wrote: Il giorno 05 settembre 2014 20:01, Daniele Varrazzo p...@develer.com ha scritto: Ho mandato patch upstream e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in pochi giorni! LOLissimo! :D molto OT: a quanto sento non sei il primo che si lamenta dell'accoglienza degli sviluppatori di ansible però il progetto è veramente valido A mio avviso hanno fatto una cappellata con la priorita' delle variabili, ma ora e' troppo tardi per tornare indietro perche' ormai ci sono ettolitri di script che fanno affidamento sul comportamento attuale. Il problema e' che loro non dicono si' abbiamo cappellato ma ormai e' cosi', che sarebbe giustificabilissimo. Loro dicono come vuoi fare tu non e' idiomatico. Insomma sbaglio io. Ok, ci puo' anche stare. Pero' googlando vedo che il problema ce l'hanno in molti. Quello che non puoi fare in ansible e' qualcosa tipo (scusate l'ansiblese per chi non lo mastica): - un role webserver definisce un default, tipo http_port = 80 - un role firewall deve poter accedere alla variabile per aprire quella porta - in un inventory vorrei avere la possibilita' di sovrascrivere questo default, ad esempio sull'installazione di test avere http_port=8080. Questo non posso farlo: se usassi include_vars nel firewall la variabile diventa troppo potente e l'inventory non puo' sovrascriverla (un default puo' essere sovrascritto invece). Se introduco una dipendenza esplicita tra i ruoli il webserver mi viene installato anche sulla macchina del firewall, che puo' essere diversa. La mia soluzione e' stata di aggiungere un comando include_defaults che funzioni come include_vars ma con le variabili overridabili. Il comportamento di ansible non cambia e se uno script non usa include_defaults tutto resta come prima. La loro risposta e' che i default condivisi vanno scritti invece... in un file globale (tipo group_vars/all). E che la nuova regola sottoporrebbe gli utenti ad un carico cognitivo eccessivo. Wat™? Insomma nei doc scrivono le variabili di inventory sono potentissime ed e' falso, puoi solo overridarci i default, se una cosa la tiri dentro con include_vars diventa semi-immortale. Dicono i role sono un modo di rendere modulare un playbook e poi ti serve un file globale per passare un default tra due role... A me sembra il caso di invocare Upton Sinclair (it is difficult to get a man to understand something, when his salary depends upon his not understanding it) e tirare avanti. Per fortuna tirare avanti si fa bene, perche' anche se non hanno accettato il nuovo comando upstream e' possibile metterlo nel proprio playbook e Ansible lo usa senza dar fastidio a nessuno. Il che mi sembra grandioso. A chi interessa include_defaults e' disponibile a https://gist.github.com/dvarrazzo/7418a89b7278ff69267c. Quindi si', confermo l'impressione: gli sviluppatori di Ansible sono *molto* opinionati. Ma il progetto e' veramente ben fatto. -- Daniele ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Il giorno 05 settembre 2014 20:34, Daniele Varrazzo p...@develer.com ha scritto: A chi interessa include_defaults e' disponibile a https://gist.github.com/dvarrazzo/7418a89b7278ff69267c. ti ringrazio per l'analisi del problema e per aver condiviso con noi la soluzione, sono sicuro che mi sarà utile in futuro -- Shipping is a feature. A really important feature. Your product must have it. Rendete ogni cosa il più semplice possibile, ma non di più (Albert Einstein) You are what you choose today, not what you've chosen before Unix IS user friendly. It's just selective about who its friend are ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi: mmm ... pricing... mmm free trial ... mmm in ogni caso mi guardo anche questo - non serve un server sulla macchina remota: basta ssh per usarlo - non serve conoscere ruby per usarlo (non serve neanche conoscere Python per usarlo, basta yaml; per Chef invece devi scrivere roba Ruby) - se ti serve hackarlo, e' scritto in Python, che si suppone tu conosca. sembra un fabric un po più potente .. o sbaglio? e mi sono gia' fatto mandare affanculo dagli sviluppatori, e tutto in pochi giorni ahahahahah :) Tuttavia il mio problema non è il deploy(e mi rendo conto di aver anche sbagliato il titolo). Il programma fa 'autodeploy'(dopo la prima installazione. Per la prima installazione mi potrei arrangiare con fabric x linux e psexec x win). Una volta che il programma è presente sul server remoto potrei renderlo in grado di aggiornare lo stesso python o al limite torno ad arrangiarmi con fabric/psexec. Il mio dubbio era più su dove installo python? Io pensavo più a qualcosa del tipo /mio/path o C:\mio\path dove dentro ci sono due directory pythonXX e mioprogramma. E' una buona prassi? potrei avere dei problemi?. Non voglio nemmeno 'inquinare' la variabile PATH. X win usare portable python potrebbe essere una buona idea? Activepython l'avete mai usato? -- Balan Victor ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] distribuire programmi python
On 2014-09-06 01:37, Balan Victor wrote: Chef e' potente ma fossi in te userei Ansible. Ha questi vantaggi: mmm ... pricing... mmm free trial ... mmm in ogni caso mi guardo anche questo Il programma e' gratis e open. A pagamento hanno dei servizi di centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono onestamente. - non serve un server sulla macchina remota: basta ssh per usarlo - non serve conoscere ruby per usarlo (non serve neanche conoscere Python per usarlo, basta yaml; per Chef invece devi scrivere roba Ruby) - se ti serve hackarlo, e' scritto in Python, che si suppone tu conosca. sembra un fabric un po più potente .. o sbaglio? In un certo senso sì: come fabric si connette via ssh ed esegue comandi. Però non è imperativo, ma dichiarativo. Ovvero, tu hai un task che dice sulla macchina deve esserci un utente che si chiama 'pippo' e appartiene al gruppo 'devs'. Oppure deve esserci la directory /foo/bar/baz proprietario root e permessi 755. apache deve essere installato almeno versione 2.2 ecc. Tu dichiari cosa vuoi ed ansible fa la differenza. Ovvero: va sulla macchina, l'utente c'è? Stapposto. La directory c'è? Ha permessi 700? Cambio i permessi. Apache c'è? No? apt-get install... Eccetera. Tu descrivi lo stato finale e il programma si incarica di verificare che quello stato sia realizzato, oppure se non c'è fa in modo di raggiungerlo. Fabric invece è puramente imperativo: tu gli dici di eseguire apt-get install apache, poi se questo fa qualcosa oppure niente perché apache c'è già non sono fatti di fabric. Ma se fai useradd e l'utente c'è già probabilmente il comando ti darà un errore che dovrai gestire, e se della directory vuoi cambiare i permessi devi gestire tipo due casi diversi: se non c'è la devi creare, se c'è devi fare chmod. Certo puoi provare a rendere idempotenti anche questi comandi (tipo usando mkdir -p che non dà errore se la dir c'è già). Ma in generale se il comando che esegui non è idempotente allora devi fare prima un controllo delle precondizioni. E poi sopra questo c'è tutta la gestione delle variabili e la generazione di file di configurazione da template. In effetti ansible lo stiamo introducendo su un sistema web piuttosto complicato il cui deploy è evoluto con: 1) si fa tutto a mano (ssh mollybox, git checkout, ah, cazz, qui c'è una libreria vecchia, pip install sqlalchemy. No a-ri-cazz, il frontend e il backend vogliono due versioni diverse... - voce dall'altra parte dell'ufficio: ehi, come mai molly è giù?) 2) virtualenv, requirements.txt e fabric. Questo sistema almeno il mondo python. L'aggiornamento diventa tipo fab up, che fa il git pull, pip install -U -r requirements, stop, start. Peccato che mentre facevamo questo al sistema si sono aggiunte un paio di istanze di redis, un rabbitmq e pure morbid perchè non ci facciamo mancare niente, e poi haproxy e dentro redis ci buttiamo roba fatta con capnproto. A coordinare questa roba virtualenv non basta. La macchina era piuttosto vecchia e lo sviluppatore che aggiungeva questa roba si doveva compilare anche il compilatore per compilare pycapnp e non so che versione di redis con dentro un interprete lua... Mi sono distratto un attimo (sono stato via dal lavoro qualche mese) e quando sono tornato si era anche scritto un sistema per 3) generare i file di configurazione da template (per qualche motivo gli era cresciuto mentre nel sistema ci buttava dentro anche supervisord). Per fortuna non gli è uscito benissimo e alcuni template hanno bisogno di un template di partenza, o qualcosa del genere di cui mi sono perso volentieri i dettagli. Insomma, per fortuna la settimana scorsa è andato in ferie lui, altrimenti mi riscriveva ansible dentro molly :) Quando si è distratto un attimo ho ansibolato tutto, ovvero a) installazione dei package e preparazione del sistema, b) installazione del nostro codice e librerie python c) generazione dei file di configurazione. Quindi ora in quei playbook di ansible c'è già quasi tutta la conoscenza del sistema (quando ha migrato la macchina vecchia alla nuova dice che c'ha messo una settimana a sistemare tutto, a forza di tentativi ed errori, ovviamente. Io ho fatto gli stessi errori, ma almeno quello che ho fatto adesso è ripetibile e in 10 minuti parte da una VM vuota a un sistema funzionante). Il sistema di template è più completo, per cui riesce a gestire le varie casistiche che ci dobbiamo smazzare (per esempio che su una macchina girano 3 istanze piccole del sito su 3 ip diversi ma quell'altro sito è grande quindi è diviso su tre macchine, frontend, backend, database, con 8 nodi frontend, 2 backend...) che a coprirle tutte con scriptini fatti a mano un po' gli saranno tremate le vene e probabilmente qualche scorciatoia l'ha presa. ...dov'eravamo? Ah sì: fabric. Sì, ansible gli somiglia, ma ci devi aggiungere sopra la gestione delle variabili e la gestione dei template di
