buildout.cfg è il file più importante nel tuo nuovo ambiente buildout. Ecco come appare:

[buildout]
parts =
    plone
    zope2
    productdistros
    instance
    zopepy

# Aggiungi sorgenti di scaricamente egg addizionali qui. dist.plone.org contiene gli archivi 
# dei pacchetti Plone.
find-links =
    http://dist.plone.org
    http://download.zope.org/ppix/
    http://download.zope.org/distribution/
    http://effbot.org/downloads

# Aggiungi egg addizionali qui
# elementtree è richiesto da Plone
eggs =
    elementtree
    
# Referenzia qualsiasi egg che stai sviluppando qui, una per linea
# esempio: develop = src/my.package
develop =

[plone]
recipe = plone.recipe.plone

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

# Usa questa sezione per scaricare prodotti vecchio stile aggiuntivi.
# Elenca tutte le URL necessarie per i tarballs dei prodotti sotto urls
# (separate da uno spazio bianco, o su più linee, con le linee successive
# indentate). Se un archivio contiene molti prodotti all'interno di una
# cartella di primo livello, elenca il filename dell'archivio (cioè
# l'ultima parte della URL, normalmente con un suffisso .tar.gz o simile)
# sotto 'nested-packages'.
# Se un archivio si estrae in una cartella product con un suffisso di versione,
# elenca il nome dell'archivio sotto 'version-suffix-packages'.
[productdistros]
recipe = plone.recipe.distros
urls =
nested-packages =
version-suffix-packages = 

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
debug-mode = on
verbose-security = on

# Se vuoi che Zope conosca un qualsiasi egg aggiuntivo, elencalo qui.
# questo dovrebbe includere qualsiasi egg di sviluppo che hai elencato
# sopra in develop-eggs, ad es. eggs = ${buildout:eggs} ${plone:eggs} my.package
eggs =
    ${buildout:eggs}
    ${plone:eggs}

# Se vuoi registrare slug ZCML per un qualsiasi pacchetto, elencalo qui.
# ad es. zcml = my.package my.other.package
zcml = 

products =
    ${buildout:directory}/products
    ${productdistros:location}
    ${plone:products}

[zopepy]
recipe = zc.recipe.egg
eggs = ${instance:eggs}
interpreter = zopepy
extra-paths = ${zope2:location}/lib/python
scripts = zopepy

Ispezioniamo questo file passo passo:

La sezione principale [buildout]

La sezione [buildout] è il punto di inizio del file. Elenca un numero di "parti" che sono configurate in sezioni separate successivamente nel file. Ogni parte ha una ricetta associata, la quale rappresenta il nome di un egg che sa come portare a termine uno specifico compito, ad esempio compilare Zope o creare una istanza Zope. Una ricetta tipicamente accetta alcune opzioni di configurazione.

Le nostre impostazioni globali sono le seguenti:

[buildout]
parts =
    plone
    zope2
    productdistros
    instance
    zopepy

find-links =
    http://dist.plone.org
    http://download.zope.org/ppix/
    http://download.zope.org/distribution/
    http://effbot.org/downloads

eggs =
    elementtree
    
develop =

Questo specifica che le parti plone, zope2, productdistros, instance and zopepy saranno eseguite in quell'ordine. Quindi diciamo a buildout che può cercare in una di una serie di URL quando deve scaricare delle egg. Inoltre cercherà sempre e comunque nel Cheese Shop.

Dopo possiamo elencare qualsiasi egg che buildout dovrebbe scaricare e installare per noi. Questo potrebbe includere la richiesta di specifiche versioni. Ad esempio, se vuoi sqlalchemy 0.3,  ma non 0.4, potresti elencare:

eggs = 
    elementtree
    sqlalchemy>=0.3,<0.4dev

Infine possiamo elencare gli egg di sviluppo, specificando una cartella dove gli egg saranno estratti in formato sorgente. Ad esempio:

eggs =
    elementtree
    my.package

develop = 
    src/my.package

Questo presuppone che esista un egg chiamato my.package nella cartella src/ . Impareremo a costruire simili egg fra un po' nel corso della guida. Nota come dobbiamo anche elencare my.package come una vera egg dipendente: le egg di sviluppo non sono automaticamente aggiunte al "working set" di egg che vengono installate per Zope.

La sezione [plone]

Questa è molto semplice - usa solo plone.recipe.plone per scaricare prodotti ed egg di Plone.

[plone]
recipe = plone.recipe.plone

Utilizzerà l'ultima release disponibile. I numeri di versione per plone.recipe.plone corrispondono ai numeri di versione di Plone stesso. Quindi per essere certo di ottenere sempre una release 3.0.x, ma non una 3.1, puoi fare così:

[plone]
recipe = plone.recipe.plone>=3.0,<3.1dev

Quando la ricetta viene eseguita, i prodotti di Plone saranno installati in parts/plone. Le egg sono rese disponibili mediante la variabile  buildout ${plone:eggs}, che referenzieremo nella sezione [instance] più avanti, e la URL di una versione nota come "buona" di Zope è disponibile nella variabile ${plone:zope2-url}.

La sezione [zope2]

Questa parte costruisce Zope 2, usando plone.recipe.zope2install. Se hai specificato una istallazione Zope esistente, non avrai questa parte. Altrimenti ha questo aspetto:

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

Qui referenziamo l'URL da cui scaricare Zope come specificato dalla parte [plone] . Questo assicura di ottenere comunque la versione raccomandata di Zope. Potresti specificare manualmente una URL di download, se volessi usare una versione diversa di Zope.

Quando la ricetta viene eseguita, Zope 2 viene installato in parts/zope2. La software home di Zope diventa parts/zope2/lib/python.

La sezione [productdistros]

Questa usa la ricetta plone.recipe.distros , che riesce a scaricare distribuzioni (archivi) di prodotti stile Zope 2 e li rende disponibili in Zope. Per cominciare è vuota:

[productdistros]
recipe = plone.recipe.distros
urls =
nested-packages =
version-suffix-packages =

In ogni caso puoi elencare qualsiasi numero di download. La ricetta è anche in grado di gestire archivi con una singola cartella di primo livello contenente un bundle di vere cartelle prodotto (nested-packages), o pacchetti che hanno un numero di versione nel nome della cartella e devono perciò essere rinominati per avere la vera cartella prodotto (version-suffix-packages).

Ad esempio, ecco come potresti scaricare CacheFu 1.1:

[productdistros]
recipe = plone.recipe.distros
urls =
    http://plone.org/products/cachefu/releases/1.1/CacheFu-1.1.tgz
nested-packages =
    CacheFu-1.1.tgz
version-suffix-packages = 

Puoi specificare download multipli usando diverse righe. Quando la ricetta viene eseguita, le cartelle prodotto dei prodotti scaricati si trovano in parts/productdistros.

La sezione [instance]

La sezione instance collega il tutto: configura un'istanza Zope usando lo script plone.recipe.zope2instance . Ecco come appare:

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
debug-mode = on
verbose-security = on
eggs =
    ${buildout:eggs}
    ${plone:eggs}
zcml = 
products =
    ${buildout:directory}/products
    ${productdistros:location}
    ${plone:products}

Qui referenziamo l'installazione Zope 2 dalla parte [zope2]: se hai specificato una posizione tu stesso quando hai creato il buildout, vedrai quella in tal caso. Quindi specifichiamo user e password dell'admin iniziale, e la porta a cui risponderà Zope. Attiviamo anche il debug mode e verbose security. Queste opzioni sono usate per generare un file zope.conf appropriato per questa istanza. Vedi la pagina della ricetta nel Cheese Shop per ulteriori dettagli sulle opzioni disponibili.

Successivamente specifichiamo quali egg saranno rese disponibili a Zope. Questo referenzia le egg "globali" dalla sezione [buildout], come pure le egg specificate da Plone. Potresti aggiungere egg ulteriori qui, sebbene risulta generalmente più semplice specificarle all'inizio del file, in modo che vengano incluse nel working set ${buildout:eggs}.

Come spiegato in precedenza, i file configure.zcml di Zope 3 non sono caricati automaticamente per le egg o i pacchetti che non si trovano nel namespace Products. Per caricare i file ZCML per un pacchetto regolare, possiamo far creare a buildout uno slug ZCML elencando il pacchetto sotto l'opzione zcml:

zcml =
    my.package
    my.package-overrides

SI presuppone che my.package fosse precedentemente referenziato nel buildout. Questo caricherebbe sia il configure.zcml principale che il file overrides.zcml da questo pacchetto.

Infine elenchiamo le varie cartelle che contengono prodotti in stile Zope 2, affine alla cartella Products/ in una istanza tradizionale. Nota come la cartella products/ nella cartella principale di buildout viene prima di tutto, seguita dai prodotti scaricati con la parte [productdistros], seguita dai prodotti scaricati dalla parte [plone]. Questo significa che se anche Plone viene distribuito con un prodotto, potresti fare un override (ad es. con un prodotto più aggiornato) mettendo un prodotto con lo stesso nome nella cartella products/ di primo livello.

Quando la ricetta viene eseguita, l'istance home di Zope sarà parts/instance, e uno script di controllo verrà generato in ./bin/instance.

La sezione [zopepy]

Questa sezione finale crea un interprete Python che dispone di tutte le egg e pacchetti (ma non dei prodotti in stile Zope 2) di cui Zope disporrà quando in esecuzione. Questo può essere utile per effettuare del testing.

[zopepy]
recipe = zc.recipe.egg
eggs = ${instance:eggs}
interpreter = zopepy
extra-paths = ${zope2:location}/lib/python
scripts = zopepy

Qui copiamo le egg dalla sezione [instance], e includiamo nella pythonpath la instance home di Zope.

Quando la ricetta viene eseguita lo script sarà generato in ./bin/zopepy.