 |
 |
 |
Installare moduli Python |  |
 |
|
|
|
|
Installare moduli Python | |
|
|
Spesso, questo è necessario, o desiderabile, per installare moduli in una posizione differente dalla posizione predefinita per i moduli di terze parti di Python. Per esempio, su un sistema Unix potreste non avere i permessi per scrivere nella directory predefinita per i moduli di terze parti. O vorreste provare un modulo prima di includerlo in una parte predefinita della vostra distribuzione Python locale. Questo è soprattutto vero quando si aggiorna una distribuzione già esistente: vorrete essere sicuri che la vostra base esistente di script lavori con la nuova versione prima dell'aggiornamento attuale.
Il comando Distutils install è progettato per eseguire
un'installazione dei moduli di una distribuzione in una posizione
alternativa in modo semplice ed indolore. L'idea principalmente è
quella di fornire una directory di base per l'installazione ed il
comando install sceglie una serie di directory (chiamamdo
uno schema d'installazione) sotto questa directory di base,
nella quale installare i file. I dettagli differiscono a seconda
delle piattaforme, così da leggere comunque le sezioni che voi
utilizzate.
Sotto Unix, ci sono due modi per effettuare un'installazione alternativa. Lo ``schema prefissato'' è simile a come le installazioni alternative lavorano sotto Windows e Mac OS, ma non è necessariamente il modo più efficace per mantenere una libreria personale Python. Perciò documenteremo prima il modo più conveniente e utile per uno ``schema casalingo''.
L'idea dietro lo ``schema casalingo'' è costruire e tenere i moduli Python personali al sicuro, probabilmente sotto la vostra directory home. L'installazione di un nuovo modulo di una distribuzione è semplice, come:
python setup.py install --home=<dir>
dove potete fornire ogni directory a piacimento per l'opzione
--home. I pigri possono digitare solo una tilde
(~); il comando install lo
espanderà alla vostra directory home:
python setup.py install --home=~
L'opzione --home definisce la directory base dell'installazione. I file verranno installati nelle seguenti directory sotto l'installazione di base come segue:
| Tipo di file | Directory d'installazione | Opzioni di sovrascrittura |
|---|---|---|
| distribuzione di moduli puri | home/lib/python | --install-purelib |
| distribuzione di moduli non puri | home/lib/python | --install-platlib |
| scripts | home/bin | --install-scripts |
| data | home/share | --install-data |
Lo ``schema prefix'' è utile quando volete usare un'installazione Python per eseguire il build/install (per esempio per avviare lo script di setup), ma volete installare i moduli in una directory di moduli di terze parti di una differente installazione Python (o qualcosa che assomigli ad una differente installazione Python). Se questo suona come un dettaglio molto insignificante è perché lo ``schema casalingo'' è già stato descritto. Pertanto, ci sono almeno due casi conosciuti dove lo schema prefissato sarebbe utile.
Per prima cosa considerate che molte distribuzioni Linux mettono Python in /usr, invece che nel più tradizionale /usr/local. Questo è assolutamente appropriato, poiché in quei casi Python è parte ``del sistema'' piuttosto che un programma aggiuntivo locale. Pertanto, se state installando i moduli Python da sorgente, probabilmente vorrete che finiscano in /usr/local/lib/python2.X, piuttosto che in /usr/lib/python2.X. Questo può essere fatto con
/usr/bin/python setup.py install --prefix=/usr/local
Un'altra possibilità è un filesystem di rete, dove il nome usato per scrivere nella directory remota è differente dal nome usato per leggerla: per esempio, l'interprete Python accedendo come /usr/local/bin/python potrebbe ricercare i moduli in /usr/local/lib/python2.X, ma questi moduli dovrebbero anche essere installati, dichiarando, /mnt/@server/export/lib/python2.X. Questo potrebbe essere fatto con
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
In entrambi i casi, l'opzione --prefix definisce l'installazione base e l'opzione --exec-prefix definisce l'installazione base per i file della piattaforma specifica. Allo stato attuale questo significa solo distribuzioni di moduli non puri, ma potrebbe essere esteso alle librerie C, ai binari eseguibili, etc. etc.. Se --exec-prefix non viene fornito, viene predefinito --prefix. I file vengono installati così:
| Tipo di file | Directory d'installazione | Opzioni di sovrascrittura |
|---|---|---|
| distribuzione di moduli puri | prefix/lib/python2.X/site-packages | --install-purelib |
| distribuzione di moduli non puri | exec-prefix/lib/python2.X/site-packages | --install-platlib |
| scripts | prefix/bin | --install-scripts |
| data | prefix/share | --install-data |
Non viene richiesto che --prefix o --exec-prefix puntino ad un'installazione Python alternativa; se le directory menzionate non esistono ancora, verranno create al momento dell'installazione.
Incidentalmente, la reale ragione per cui lo schema
prefix è importante è che l'installazione standard Unix usa lo
schema prefix, ma con --prefix ed
--exec-prefix forniti da Python stesso come
sys.prefix e sys.exec_prefix. Così, potreste
pensare di non usare mai lo schema prefix, ma in realtà, ogni volta
che eseguirete python setup.py install senza nessun'altra
opzione, ne farete uso.
Notate che installando le estensioni in un'installazione alternativa di Python non ci saranno effetti su come queste estensioni sono state compilate: in particolare, i file d'intestazione di Python (Python.h e compagnia), installati con l'interprete usato per eseguire lo script di setup, verranno usati nella compilazione delle estensioni. È vostra responsabilità assicurarvi che l'interprete usato per eseguire l'installazione delle estensioni in questo modo sia compatibile con l'interprete usato per compilarle. Il modo migliore per assicurarvene è controllare che i due interpreti siano della stessa versione di Python (possibilmente di differenti compilazioni o magari copie della stessa compilazione). Naturalmente, se i vostri --prefix e --exec-prefix non puntano parimenti ad un'installazione alternativa di Python, questo è irrilevante.
Poiché Windows non ha nessuna concezione della directory home degli utenti e poiché l'installazione standard di Python sotto Windows è più semplice che sotto Unix, non ci sono differenze tra le opzioni --prefix ed --home. Usate soltanto l'opzione --prefix per specificare una directory base. Per esempio:
python setup.py install --prefix="\Temp\Python"
per installare i moduli nella directory \Temp\Python del disco corrente.
L'installazione viene definita dall'opzione --prefix; l'opzione --exec-prefix non è supportata sotto Windows. I file vengono installati così:
| Tipo di file | Directory d'installazione | Opzioni di sovrascrittura |
|---|---|---|
| distribuzione di moduli puri | prefix | --install-purelib |
| distribuzione di moduli non puri | prefix | --install-platlib |
| scripts | prefix\Scripts | --install-scripts |
| data | prefix\Data | --install-data |
Come Windows, Mac OS non ha nozione delle home directory (o degli utenti), ha una semplice installazione standard di Python. Quindi è necessaria solamente un'opzione --prefix. Questa definisce la base dell'installazione ed i file vengono installati al di sotto di essa, nel seguente modo:
| Tipo di file | Directory d'installazione | Opzioni di sovrascrittura |
|---|---|---|
| distribuzione di moduli puri | prefix:Lib:site-packages | --install-purelib |
| distribuzione di moduli non puri | prefix:Lib:site-packages | --install-platlib |
| scripts | prefix:Scripts | --install-scripts |
| data | prefix:Data | --install-data |
Vedete la sezione 2.1 per informazioni su come fornire ulteriori argomenti da riga di comando allo script di setup con MacPython.
|
|
|
Installare moduli Python | |
|
|