Come mantenere progetti python longevi w.r.t. dipendenze e versioni python?

Question

versione corta: come posso liberarmi dell'incubo di versioni multiple di Python?

versione lunga: nel corso degli anni, ho usato diverse versioni di pitone, e quel che è peggio, molti estensioni a Python (ad esempio pygame, pylab, wxPython ...). Ogni volta era su una configurazione diversa, con sistemi operativi diversi, a volte architetture diverse (come il mio vecchio Mac PowerPC).

Al giorno d'oggi sto usando un mac (OSX 10.6 su x86-64) ed è un incubo di dipendenza ogni volta che voglio far rivivere script più vecchio di qualche mese. Python stesso è già disponibile in tre diversi formati in /usr/bin (2.5, 2.6, 3.1), ma ho dovuto installare 2.4 da macports per pygame, qualcos'altro (non ricordo cosa) mi ha costretto a installare tutti e tre gli altri da macports, quindi a Alla fine della giornata sono il felice proprietario di sette istanze (!) di python sul mio sistema.

Ma non è questo il problema, il problema è che nessuno di essi ha le librerie giuste (cioè lo stesso set di) installate, alcune di esse sono a 32 bit, a 64 bit, e ora sono praticamente perse.

Ad esempio, ora sto provando a eseguire uno script di tre anni (non scritto da me) che usava matplotlib/numpy per disegnare un grafico in tempo reale all'interno di un rettangolo di una finestra wxwidgets. Ma sto fallendo miseramente: py26-wxpython da macports non si installerà, stock python include wxwidgets ma ha anche qualche conflitto tra 32 bit e 64 bit, e non ha numpy ... che casino!

Ovviamente, sto facendo le cose nel modo sbagliato. Come fa tu far fronte a tutto quel caos?

Answer 1

Alcuni consigli:

• su Mac OS X, utilizzare solo l'installazione Python in /Library/Frameworks/Python.framework.
• ogni volta che si utilizza NumPy/SciPy/matplotlib, installare la distribuzione Enthought pitone
• uso virtualenv e virtualenvwrapper per mantenere gli impianti "di sistema" incontaminata; utilizzare idealmente un ambiente virtuale per progetto, in modo che le dipendenze di ciascun progetto siano soddisfatte. E, sì, questo significa che potenzialmente molti codici verranno replicati nei vari virtual envs.

Sembra un vero casino, ma almeno le cose funzionano in questo modo. In sostanza, se uno dei progetti funziona in virtualenv, continuerà a funzionare indipendentemente dagli aggiornamenti che si eseguono, dal momento che non si cambiano mai le installazioni di "sistema".

Answer 2

Dai uno sguardo allo virtualenv.

Answer 3

Quello che faccio di solito è provare (progressivamente) a stare al passo con le versioni di Python mentre arrivano (e una volta che tutte le dipendenze esterne hanno versioni corrette disponibili).

La maggior parte delle volte il codice Python stesso può essere trasferito così come è, con solo piccole modifiche necessarie.

Il mio più grande progetto Python @ work (15.000+ LOC) è ora in Python 2.6 di pochi mesi (l'aggiornamento di tutto, dai Python 2.5 ha preso più di un giorno a causa di installazione/controllo 10+ dipendenze ...)

In generale penso che questa sia la migliore strategia con la maggior parte dei componenti interdipendenti nello stack di software libero (si pensi alle dipendenze nei repository software Linux): mantieni le tue versioni (semi) -correnti (o almeno: progredendo allo stesso ritmo).

Answer 4

Risolvo usando virtualenv. Sono solidale con il voler evitare ulteriori strati di astrazione da incubo, ma lo virtualenv è in realtà incredibilmente pulito e semplice da usare. È letteralmente fare questo (riga di comando, Linux):

virtualenv my_env 

Questo crea un nuovo binario di pitone e la posizione biblioteca e link simbolici alle librerie di sistema esistenti per impostazione predefinita. Quindi, per cambiare percorso per utilizzare il nuovo ambiente, fai questo:

source my_env/bin/activate 

Questo è tutto. Ora se si installano i moduli (ad esempio con easy_install), vengono installati nella directory lib della directory my_env.Non interferiscono con le librerie esistenti, non si verificano conflitti strani, le cose non smettono di funzionare nel vecchio ambiente. Sono completamente isolati.

Per uscire l'ambiente, basta fare

deactivate 

Se si decide hai fatto un errore con un'installazione, o non si vuole che l'ambiente più, basta cancellare la directory:

rm -rf my_env 

E il gioco è fatto. È davvero così semplice.

virtualenv è fantastico. ;)

Answer 5

Io uso la versione MacPorts per tutto, ma come si nota molte delle versioni predefinite sono bizzarramente vecchie. Ad esempio, vim omnicomplete in Snow Leopard ha python25 come dipendenza. Molte porte relative a Python hanno vecchie dipendenze ma in genere è possibile contrassegnare la versione più recente al momento della compilazione, ad esempio port install vim +python26 anziché port install vim +python. Esegui un ciclo di prova prima di installare qualsiasi cosa per vedere se stai tirando, per esempio, l'intero python24 quando non è necessario. Controllare portfiles spesso perché la convenzione di denominazione come le porte Darwin stava decollando lasciando qualcosa a desiderare. In pratica, lascio tutto nelle cartelle predefinite di MacPorts di /opt..., inclusa una copia dell'intero framework con duplicati di PyObjC, ecc., E rimango con una versione alla volta, conservando l'opzione di tornare al default di sistema se le cose rottura inaspettata. Il che forse è un po 'troppo lavoro per evitare l'uso di virtualenv, che ho intenzione di usare.

Answer 6

Ho avuto fortuna usando il Buildout. Si imposta un elenco di quali uova e quali versioni si desidera. Buildout quindi scarica e installa versioni private di ciascuno per te. Crea un binario privato "python" con tutte le uova già installate. Un "nosetest" locale facilita il debug delle cose. Puoi estendere la build con le tue funzioni.

Sul lato negativo, Buildout può essere piuttosto misterioso. Fai "buildout -vvvv" per un po 'per vedere esattamente cosa sta facendo e perché.

http://www.buildout.org/docs/tutorial.html

Answer 7

• installare le versioni di Python è necessario, meglio se da fonti
• quando si scrive una sceneggiatura, includono la versione completa di pitone in esso (come ad esempio #!/usr/local/bin/python2.6)

I non riesco a vedere cosa potrebbe andare storto.

Se qualcosa va, è probabilmente colpa di Macports comunque, non la tua (uno dei motivi per cui non uso più Macport).

So che sto probabilmente manca qualcosa e questo otterrà downvoted, ma si prega di lasciare almeno un piccolo commento in questo caso, grazie :)

Answer 8

Almeno sotto Linux, più pitoni possono coesistere abbastanza felicemente. Io uso Python 2.6 su un sistema CentOS che ha bisogno di Python 2.4 per essere l'impostazione predefinita per varie cose di sistema. Ho semplicemente compilato e installato python 2.6 in un albero di directory separato (e ho aggiunto la directory bin appropriata al mio percorso) che era abbastanza indolore. Viene quindi richiamato digitando "python2.6".

Una volta che i pitoni separati sono operativi, l'installazione di librerie per una versione specifica è semplice. Se invochi lo script setup.py con il python che desideri, verrà installato nelle directory appropriate a quel python, e gli script verranno installati nella stessa directory dell'eseguibile python stesso e verranno automaticamente utilizzati il ​​python corretto quando viene richiamato.

Inoltre, si tenta di evitare l'utilizzo di troppe librerie. Quando ho solo bisogno di una o due funzioni da una libreria (ad esempio scipy), vedrò spesso se riesco a copiarle nel mio progetto.