2013/12/15 Enrico Bianchi <enrico.bian...@ymail.com> > On 12/14/2013 11:05 AM, enrico franchi wrote: > > Avendo spedito questo messaggio alle 16.47, e non vedendolo tutt'ora, non > riesco a capire se sia arrivato o meno. In caso mi scuso per il doppio posto > > > Se avete un sistema un po' modernino con oggetti tipo chef o puppet (o >> quello che va di moda ora) e jenkins (o quello che va di moda ora), il >> problema di gestirvi la vostra versione di Python e delle librerie che >> contano non e' particolarmente pesante. Sono un po' di madonne al >> setup e poi fine. >> > Quindi la tua idea e` compilare Python 3.3 in una directory (e.g. > /opt/python3), installare in site-packages le librerie che mi interessano e > poi distribuirlo tramite puppet, chef o altro? L'idea e` interessante, > anche se non e` quello che volevo > > > Oh, giusto per i cliche', i syseng che se la prendono con gli >> sviluppatori... ;) >> >
> Clche` fino ad un certo punto. La situazione attuale e` questa, ovvero > che le distribuzioni se ne lavano le mani motivando la loro scelta con "e` > stabile, quindi e` buono fino alla prossima release" e che i developer di > alcuni software se ne lavano le mani motivando la loro scelta con "se vuoi > l'ultima versione compilatelo, altrimenti usa la versione proposta dalla > distribuzione". Il che rende la questione un ginepraio. No aspetta… la distro si fa le sue policy e fine. Se si mantiene consistente con esse, e' solo la scelta di chi la usa. Ovvero se quelle policy sono accettabili per l'uso o cosa [0]. Chi sviluppa un pacchetto open source, in generale non ha le risorse per provarlo come si deve sulle varie piattaforme. Sinceramente, per quanto sarebbe bello avere il lavoro fatto, non e' il loro mestiere. Dovrebbe essere, appunto, il lavoro di chi fa la distribuzione. Detto questo, e' abbastanza chiaro che con il numero esorbitante di pacchetti che sono la fuori e con il fatto che non esiste un modo di deploy univoco, ci saranno assolutamente buchi neri. Anche perché' per un pacchetto giovane, i 6 mesi *minimo* di ritardo che le distribuzioni hanno per aggiornarsi sono eternità. Ci sono poi sempre i vari casi dei bugfix. E il fatto che, alla fine dei conti, i package manager sono pensati per il caso medio. Non solo, certi software si "sdoppiano" come software infrastrutturale. Per esempio, python e' un componente essenziale di molte distribuzioni. E io voglio che sia ben integrato e testato. Viceversa, per il mio servizio, non vedo assolutamente strano volere una versione diversa di python o di qualche libreria altamente usata. Per cui il problema "mi devo mantenere il deploy di un po' di software" mi sembra relativamente inevitabile. E condiviso, altrimenti oggetti come maven non avrebbero quasi ragion d'essere. > Puppet e similari risolvono parzialmente, perche` va sempre fatto un > lavoro di manutenzione a monte che va a fare da collante a quello che fa la > distribuzione e non sempre risolve. No, puppet e simili sono un componente del deploy di software nel 2013. La distribuzione non può affrontare le esigenze di tutti quanti e farlo bene. La distribuzione deve darti una piattaforma per il caso medio e renderti sano customizzarti quello che ti serve diverso. > Ma, soprattutto, un approccio del genere fa decadere lintero concetto di > distribuzione. A 'sto punto, se devo fare le cose a mano, tanto vale > consigliare Slackware o FreeBSD, con una preferenza per quest'ultimo, che > almeno segue un concetto di distribuzione sensato (il sistema base lo > aggiorna in un modo, il resto tramite ports e pkgtools) Niente da dire contro freebsd… a me i ports piacciono parecchio. Semplicemente un sistema di deploy funzionante che tratta tutta l'infrastruttura e' parte integrante del fare system engineering nell'eta' moderna. Fra l'altro, niente niente, hai componenti custom, componenti proprietari, hai di tutto... Perche' semplicemente ci sono esigenze che *nessuna* distribuzione può risolverti. > Come dire, se avete sviluppatori che non capiscono una fava di ops, >> avete un problema nell'hiring, non nella categoria di sviluppatori. >> > > Non e` un problema di sviluppo in se (anche perche` da me si usa Java, > non Python), ma del voler fare le cose come si deve. Ci sono software meno > critici che non si fanno problemi per preparare pacchetti per questa o > quell'altra distribuzione, non riesco a capire quindi perche` un software > critico come python non lo faccia Non mi sembrerebbe particolarmente sensato… Quello che tu vuoi, costa. E Python non ha dietro una multinazionale. Sai quante persone ci vorrebbero per gestire la pacchettizzazione per le maggiori distribuzioni (e quelle piccole, poverette?) Secondo me il modello in cui le distribuzioni scelgono cosa mantenere e lo mantengono e' tutto sommato il meno peggio. -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python