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: