3. Scrivere il file di configurazione di setup

Spesso, non è possibile scrivere ogni cosa necessaria per costruire una distribuzione a priori: si potrebbe aver bisogno di ottenere qualche informazione dall'utente, o dal sistema dell'utente, per poter proseguire. Tanto più l'informazione è semplice--un elenco di directory dove cercare per file di intestazione C o le librerie, per esempio--che fornire un file di configurazione, setup.cfg, da editare da parte degli utenti, diviene un modo semplice ed economico per risolvere la questione. Il file di configurazione permette di fornire dei valori predefiniti per ogni opzione di comando, che l'installatore può sovrascrivere sia con la riga di comando che editando il file di configurazione.

Il file di configurazione di setup è una utile via di mezzo tra lo script di setup--che, idealmente, dovrebbe essere nascosto agli installatori 3.1--e la riga di comando dello script di setup, che è fuori dal proprio controllo ed interamente sotto quello dell'installatore. Infatti, setup.cfg (ed ogni altro file di configurazione di Distutils presente sul sistema di destinazione) viene elaborato dopo il contenuto dello script di setup, ma prima della riga di comando. Questo ha diverse utili conseguenze:

La sintassi di base del file di configurazione è semplice:

[command]
option=value
...

dove command è uno dei comandi di Distutils (come, ad esempio build_py, install) e option è una delle opzioni che il comando supporta. Qualsiasi numero di opzioni può essere fornito per ogni comando ed ogni numero di sezioni di comandi possono essere incluse nel file. Le righe vuote vengono ignorate, come lo sono i commenti che iniziano con un carattere "#" fino alla fine della riga. Valori di opzioni lunghe possono essere suddivise in righe multiple semplicemente indentando la riga di continuazione.

Si può verificare l'elenco delle opzioni supportate da un particolare comando con l'universale opzione --help, per esempio:

> python setup.py --help build_ext
[...]
Opzioni per il comando 'build_ext':
  --build-lib (-b)     directory per i moduli di estensioni compilati
  --build-temp (-t)    directory per i file temporanei (prodotti dalla 
                       compilazione)
  --inplace (-i)       ignora build-lib ed inserisce le estensioni compilate 
                       nella directory dei sorgenti, accanto ai moduli Python
  --include-dirs (-I)  elenco di directory dove cercare i file di intestazione
  --define (-D)        macro del preprocessore C da definire
  --undef (-U)         macro del preprocessore C da non definire
[...]

Si noti che un'opzione indicata --foo-bar da riga di comando viene chiamata foo_bar nel file di configurazione.

Per esempio, si decide di volere la propria estensione compilata ``sul posto''--che significa che si ha una estensione pkg.ext e si vuole che il file di estensione compilato (ext.so in Unix, diciamo) sia inserito nella stessa directory sorgente, come i propri moduli Python pkg.mod1 e pkg.mode2. Si può sempre utilizzare l'opzione --inplace da riga di comando per ottenere ciò:

python setup.py build_ext --inplace

Ma questo richiede che si specifichi sempre il comando build_ext esplicitamente, e di ricordarsi di indicare --inplace. Un modo semplice è di ``impostare e dimenticare'' questa opzione, codificandola in setup.cfg, ovvero il file di configurazione per questa distribuzione

[build_ext]
inplace=1

Questo influenzerà tutte le compilazioni di questa distribuzione di moduli, indipendentemente se si specifica esplicitamente build_ext. Se si include setup.cfg nella propria distribuzione di sorgenti, influenzerà anche le compilazioni finali dell'utente--che è probabilmente una cattiva idea per questa opzione, in quanto ogni compilazione di estensioni in loco interromperebbe l'installazione della distribuzione di moduli. In certi casi particolari, comunque, i moduli vengono compilati proprio nella loro directory di installazione, (Distribuire estensioni che si aspettano di essere compilate nella medesima directory d'installazione costituiscono comunque sempre un modo di procedere sbagliato.)

Un altro esempio: alcuni comandi dispongono di parecchie opzioni che non cambiano da esecuzione ad esecuzione; per esempio, bdist_rpm deve sapere tutto quanto possa servire per generare un file ``spec'' per creare una distribuzione RPM. Alcune di queste informazioni arrivano dallo script di setup, ed altre vengono automaticamente generate da Distutils (come la lista dei file installati). Ma alcune di queste devono essere indicate come opzione a bdist_rpm e potrebbe risultare molto noioso da farsi sulla riga di comando ad ogni esecuzione. Pertanto, ecco un piccolo estratto da un file setup.cfg personalizzato di Distutils:

[bdist_rpm]
release = 1
packager = Greg Ward <gward@python.net>
doc_files = CHANGES.txt
            README.txt
            USAGE.txt
            doc/
            examples/

Si noti che l'opzione doc_files è semplicemente una stringa separata da spazi vuoti, suddivisa in righe multiple per una migliore leggibilità.

Vedete anche:

Installazione di moduli Python
Ulteriori informazioni sui file di configurazione sono disponibili nel manuale per gli amministratori di sistema.



Footnotes

... installatori3.1
Questo meccanismo probabilmente non verrà ottenuto finché l'auto-configurazione non verrà pienamente supportata dalle Distutils
Vedete Circa questo documento... per informazioni su modifiche e suggerimenti.