[Python] distribuire programmi python

[Balan Victor]

Ciao a tutti,
ho un programma scritto in python che devo far girare su server
linux/aix/hp-ux/unix/solaris e windows. Il programma è scritto per python
3.4 ma dovrebbe funzionare con tutte le altre versioni precedenti. Qual'è
il miglior modo di farlo girare su tutti questi sistemi ?

Usare tool come py2exe, pyinstaller o simili?
Installare python su ogni sistema e poi far girare il
programma(/path/to/python mioprogramma.py) ?
Usare ActivePython?


Qualcuno ha mai dovuto distribuire programmi python su ambienti diversi?
Come avete fatto ?

-- 
Balan Victor
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[enrico franchi]

2014-09-04 13:51 GMT+01:00 Balan Victor :

> ho un programma scritto in python che devo far girare su server
> linux/aix/hp-ux/unix/solaris e windows. Il programma è scritto per python
> 3.4 ma dovrebbe funzionare con tutte le altre versioni precedenti.
>

Diciamo cosi', se non hai fatto esplicitamente in modo che sia cosi' e non
lo hai provato, ho seri dubbi in proposito.



> Qual'è il miglior modo di farlo girare su tutti questi sistemi ?
>

> Usare tool come py2exe, pyinstaller o simili?
> Installare python su ogni sistema e poi far girare il
> programma(/path/to/python mioprogramma.py) ?
> Usare ActivePython?
>

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*?

Poi sul discorso deploy si dovrebbe aprire un lungo discorso (puppet/chef +
docker convocati...).

Se invece hai scritto il tuo pacchetto e vuoi che altri lo usino:
- pip e' probabilmente la cosa piu' comoda. Se non hai codice compilato fra
le scatole.
- La gente di Unix si aspetta il sorgente, verosimilmente pip, e se proprio
vuoi strafare pacchetti per alcune distribuzioni (che e' comunque non
inusuale che se prende trazione qualcuno li faccia per te)
- La gente di Windows... boh. Immagino che se sono sviluppatori o
sistemisti siano contenti con pip. Se no direi che *a loro* interessa un
qualche installer. Ma non ti so dire, non ci tratto.

Qualcuno ha mai dovuto distribuire programmi python su ambienti diversi?
> Come avete fatto ?
>

Io pero' non tratto con Windows, come dicevo.

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Balan Victor]

>
> 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.

-- 
Balan Victor
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[enrico franchi]

2014-09-04 23:49 GMT+01:00 Balan Victor :

> 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

[Balan Victor]

>
> 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

[Daniele Varrazzo]

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

[Francesco Pischedda]

Il giorno 05 settembre 2014 20:01, Daniele Varrazzo  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


-- 
"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

[Daniele Varrazzo]

On 2014-09-05 19:04, Francesco Pischedda wrote:
Il giorno 05 settembre 2014 20:01, Daniele Varrazzo 
 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 
.


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

[Francesco Pischedda]

Il giorno 05 settembre 2014 20:34, Daniele Varrazzo  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

[Balan Victor]

>
> 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

[Daniele Varrazzo]

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 de

Re: [Python] distribuire programmi python

[Balan Victor]

il giorno 06 settembre 2014 04:30, Daniele Varrazzo  ha
scritto:

> 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.
>
ottima introduzione XD

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' 

Re: [Python] distribuire programmi python

[Daniele Varrazzo]

On 2014-09-06 06:46, Balan Victor wrote:
il giorno 06 settembre 2014 04:30, Daniele Varrazzo 
 ha

scritto:



devi provare dell'oddio verso il tuo collega .. ahahah


Assolutamente no, è un bravissimo ragazzo e una delle persone più 
pazienti del mondo. Per lui risolvere un bug tipo cambiare l'anno di 
copyright a fondo pagina oppure stravolgere completamente il sistema 
sono la stessa cosa. Lo ammiro, io passo sempre per la strada più pigra 
:)




Su *nix compila python installandolo in /usr/local/py34 (./configure
--prefix=/usr/local/py34 && make && sudo make install) e crea un 
virtualenv
che utilizzi quell'eseguibile. Puoi avere diverse versioni di Python 
e non
si danno minimamente fastidio (ho tutta la collezione dal 2.4 al 3.4 
sul

portatile e sulle macchine di test).


si effettivamente non c'ho minimamente pensato ...

mai avuto esperienze con python e z/os / mvs ?


Non credo ci trovi niente di più aggiornato di Python 2.4 per questa 
roba.


-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Giovanni Porcari]

> Il giorno 05/set/2014, alle ore 18:28, enrico franchi 
>  ha scritto:
> 
> 2014-09-04 23:49 GMT+01:00 Balan Victor :
> 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...
> 

Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire
che tipo di controindicazioni ci vedete ?

Grazie :)

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Daniele Varrazzo]

On 2014-09-06 12:01, Giovanni Porcari wrote:

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...



Dal momento che mi sono totalmente 'innamorato' di docker mi potreste 
dire

che tipo di controindicazioni ci vedete ?


Penso solo questo:

On 2014-09-04 13:51, Balan Victor wrote:

Ciao a tutti,
ho un programma scritto in python che devo far girare su server
linux/aix/hp-ux/unix/solaris e windows.


Docker gira solo su Linux moderni. Victor insiste che il suo programma 
scritto in Py 3.4 deve girare anche sul VIC20...


-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Roberto De Ioris]

>
>> Il giorno 05/set/2014, alle ore 18:28, enrico franchi
>>  ha scritto:
>>
>> 2014-09-04 23:49 GMT+01:00 Balan Victor :
>> 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...
>>
>
> Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire
> che tipo di controindicazioni ci vedete ?
>


Per quello che posso dirti e' sempre tutto una scuola di pensiero:

parlo con un "devops" e si esalta per docker, lxc e compagnia bella, parlo
con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E
il bello e' che succede anche il contrario :)

Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una
rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non
si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle
shared libraries), ma dall'altro lato la deduplicazione di file, librerie
e binari di sistema che si portano dietro questi sistemi richiedono una
grande responsabilita' (qualita' che spesso si costruisce in anni di
esperienza da sysadmin e non a colpi di tool 'fashion').

La stessa cosa ad esempio succede con Go, il fatto che sia tutto compilato
staticamente (almeno per ora) fa storcere il naso a parecchi... Chi ha
ragione ? Boh :)

Per come la vedo io il mondo dei container e' una cosa che non si puo'
ignorare, e sono contento che Docker abbia avuto successo perche' ha fatto
uscire dalle caverne una sfilza di sysadmin intrappolati negli anni 70
convinti che il paradigma UNIX sia perfetto cosi' (ma vaff...)

Basta solo ricordarsi che gli aggiornamenti di sicurezza vanno fatti, e
vanno fatti per sempre (e se il cliente non vuole pagare per questo
servizio NECESSARIO e' meglio che vi firmi qualche bella cartaccia
dall'avvocato)


-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Roberto De Ioris]

>
>>
>> Dal momento che mi sono totalmente 'innamorato' di docker mi potreste
>> dire
>> che tipo di controindicazioni ci vedete ?
>>
>
>
> Per quello che posso dirti e' sempre tutto una scuola di pensiero:
>
> parlo con un "devops" e si esalta per docker, lxc e compagnia bella, parlo
> con un sysadmin o un esperto di distro e gli vengono i brividi freddi. E
> il bello e' che succede anche il contrario :)
>
> Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre una
> rottura di scatole (ma questo e' spesso colpa degli sviluppatori che non
> si curano di chi dovra' usare i loro prodotti, vedi rant di Linus sulle
> shared libraries), ma dall'altro lato la deduplicazione di file, librerie


scusate qui intendevo "duplicazione" :)

-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Daniele Varrazzo]

On 2014-09-06 12:36, Roberto De Ioris wrote:

Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre 
una
rottura di scatole (ma questo e' spesso colpa degli sviluppatori che 
non
si curano di chi dovra' usare i loro prodotti, vedi rant di Linus 
sulle

shared libraries)


Link or it didn't happen :)

-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Balan Victor]

Il giorno 06 settembre 2014 13:33, Daniele Varrazzo  ha
scritto:

> On 2014-09-06 12:01, Giovanni Porcari wrote:
>>
>> Dal momento che mi sono totalmente 'innamorato' di docker mi potreste dire
>> che tipo di controindicazioni ci vedete ?
>>
>
> Penso solo questo:
>
> On 2014-09-04 13:51, Balan Victor wrote:
>
>> Ciao a tutti,
>> ho un programma scritto in python che devo far girare su server
>> linux/aix/hp-ux/unix/solaris e windows.
>>
>
> Docker gira solo su Linux moderni. Victor insiste che il suo programma
> scritto in Py 3.4 deve girare anche sul VIC20...

ahahah ... in realtà mi accontento solo di win e linux tutte le altre
piattaforme sono un 'di più' che non fa male ma che se c'è bene se non c'è
amen

Per come la vedo io il mondo dei container e' una cosa che non si puo'
> ignorare, e sono contento che Docker abbia avuto successo perche' ha fatto
> uscire dalle caverne una sfilza di sysadmin intrappolati negli anni 70
> convinti che il paradigma UNIX sia perfetto cosi' (ma vaff...)

 come ho scritto qualche mail sopra il programma deve girare su server
dedicati ad altre applicazioni(raccoglie metriche e fa 'query') quindi non
posso isolare il programma, e poi almeno la metà dei server è win.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Daniele Varrazzo]

On 2014-09-06 14:27, Balan Victor wrote:

Docker gira solo su Linux moderni. Victor insiste che il suo 
programma

scritto in Py 3.4 deve girare anche sul VIC20...


ahahah ... in realtà mi accontento solo di win e linux tutte le altre
piattaforme sono un 'di più' che non fa male ma che se c'è bene se 
non c'è

amen


Fa male.


-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Roberto De Ioris]

> On 2014-09-06 12:36, Roberto De Ioris wrote:
>
>> Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre
>> una
>> rottura di scatole (ma questo e' spesso colpa degli sviluppatori che
>> non
>> si curano di chi dovra' usare i loro prodotti, vedi rant di Linus
>> sulle
>> shared libraries)
>
> Link or it didn't happen :)
>
>

Eh hai ragione, ma mica mi ricordo che intervista era :)

Il succo era che si lamentava del fatto che molti sviluppatori di librerie
non si curassero di rompere le ABI (non le API) complicando la vita a
molti utilizzatori.

Me lo ricordo perche' prima di sentirlo non mi ero mai curato di rompere
le ABI :)


-- 
Roberto De Ioris
http://unbit.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Dario Bertini]

Appoggio anch'io Ansible.

Io ed un mio amico fra l'altro ci siamo creati dei playbook per
configurare i nostri stessi desktop.

Ed anch'io sono dell'idea che la leadership di Ansible sia poco
illuminata. Il mio pet peeve è il loro setup.py, che è rotto (python
setup.py install fallisce in alcuni contesti) in quanto usano delle
feature di setuptools nel setup.py, ma si ostinano ad usare
distutils... fra le conseguenze, `setup.py develop` non funziona

ma a loro non gliene interessa e rifiutano le PR, tanto hanno il loro
hacking/env_setup script... perchè fare le cose nel modo corretto che
supporta il workflow di tutti gli altri, quando possiamo riscrivere il
codice del setup, in una versione monca?


https://github.com/ansible/ansible/pull/3829


2014-09-06 15:48 GMT+02:00 Roberto De Ioris :
>
>> On 2014-09-06 12:36, Roberto De Ioris wrote:
>>
>>> Ammetto che il problema delle dipendenze nel mondo UNIX e' da sempre
>>> una
>>> rottura di scatole (ma questo e' spesso colpa degli sviluppatori che
>>> non
>>> si curano di chi dovra' usare i loro prodotti, vedi rant di Linus
>>> sulle
>>> shared libraries)
>>
>> Link or it didn't happen :)
>>
>>
>
> Eh hai ragione, ma mica mi ricordo che intervista era :)
>

Non era uno di questi 2 thread?
https://lkml.org/lkml/2012/9/30/108
https://gcc.gnu.org/ml/gcc/2001-02/msg00898.html
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Marco Beri]

On Sep 6, 2014 8:15 AM, "Daniele Varrazzo"  wrote:

> Il programma e' gratis e open. A pagamento hanno dei servizi di
centralizzazione, inventari dinamici, cose che neanche ho capito cosa sono
onestamente.

Daniele,
un collega mi ha accennato a Saltstack.

Conosci? Qualcun'altro qui?

Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Daniele Varrazzo]

On 2014-09-07 17:08, Marco Beri wrote:

On Sep 6, 2014 8:15 AM, "Daniele Varrazzo"  wrote:


Il programma e' gratis e open. A pagamento hanno dei servizi di
centralizzazione, inventari dinamici, cose che neanche ho capito cosa 
sono

onestamente.

Daniele,
un collega mi ha accennato a Saltstack.

Conosci? Qualcun'altro qui?


Io no. Da quanto ho letto implementa grossomodo lo stesso modello di 
ansible (ovvero senza server remoto, al contrario di chef/puppet). Di 
default una 0mq invece di ssh come trasporto, che lo rende un po' più 
veloce ma che ha causato problemi di sicurezza in passato (in ansible è 
opzionale). Entrambi stanno ricevendo interesse da gente che ha trovato 
chef/puppet difficili. Esperienza diretta non ne ho.


-- Daniele
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Marco Beri]

On Sep 7, 2014 10:45 PM, "Daniele Varrazzo"  wrote:
>
> On 2014-09-07 17:08, Marco Beri wrote:
>> Daniele,
>> un collega mi ha accennato a Saltstack.
>> Conosci? Qualcun'altro qui?
>
>
> Io no. Da quanto ho letto implementa grossomodo lo stesso modello di
ansible (ovvero senza server remoto, al contrario di chef/puppet). Di
default una 0mq invece di ssh come trasporto, che lo rende un po' più
veloce ma che ha causato problemi di sicurezza in passato (in ansible è
opzionale). Entrambi stanno ricevendo interesse da gente che ha trovato
chef/puppet difficili. Esperienza diretta non ne ho.
> -- Daniele

Grazie.
Ciao.
Marco.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] distribuire programmi python

[Dario Bertini]

2014-09-07 19:00 GMT+02:00 Daniele Varrazzo :
> Da quanto ho letto implementa grossomodo lo stesso modello di ansible
> (ovvero senza server remoto, al contrario di chef/puppet).

In verità mi pare che sia proprio più simile a chef/puppet che ad
ansible, in quanto di default prevede l'installazione di un master e
l'installazione di software anche sui minion

http://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html#salt-masterless-quickstart

è possibile usarlo masterless (proprio come è possible usare
chef-solo), ma non è la stessa cosa
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python