Ora siamo pronti per creare un nuovo buildout. Il "buildout" è una cartella contenente tutte le parti che realizzano un progetto, inclusa una instanza Zope, i sorgenti Plone, opzioni di configurazione personalizzate e il codice sorgente del tuo progetto. Creane uno in questo modo:

$ paster create -t plone3_buildout myproject

Questo ti farà una serie di domande. Se vuoi usare una installazione esistente di Zope piuttosto che lasciare che buildout ne scarichi e compili una per te, specifica una path assoluta come zope2_install. Analogamente, se non vuoi che buildout scarichi i prodotti del nucleo di Plone, puoi farlo puntare ad una cartella esistente che contenga tutti i prodotti necessari (scaricherà ugualmente le egg di Plone 3, ma, come vedremo in seguito, è possibile condividere una cartella di egg tra vari buildout). Dovrai inserire username and password per un Amministratore Zope, e potresti voler attivare debug mode e verbose security durante lo sviluppo.

Ora spostati nella cartella myproject appena creata, ed esegui lo script di bootstrap di buildout:

$ cd myproject
$ python bootstrap.py

Questo genererà una serie di cartelle e script e scaricherà l'ultima versione dell'egg di zc.buildout. Tutto ciò dovrebbe essere necessario solo una prima volta.

Per partire direttamente esegui:

$ ./bin/buildout

Questo legge il file buildout.cfg generato ed esegue le sue varie "parti", predisponendo Zope, creando una istanza Zope, scaricando ed installando Plone. A breve spiegheremo in maggior dettaglio questo file.

Dovrai rieseguire ./bin/buildout ogni volta che modificherai buildout.cfg. Se non vuoi che buildout vada online a cercare versioni aggiornate degli egg o che scarichi altri archivi, puoi eseguirlo in modalità offline con:

$ ./bin/buildout -No

Per avviare Zope, esegui:

$ ./bin/instance fg

Lo script instance è analogo a zopectl che trovi nell'istanza Zope standard. Puoi usare ./bin/instance start per eseguire Zope in modalità servizio. Può anche essere usato per eseguire i test:

$ ./bin/instance test -s plone.portlets

Cartelle nel buildout

Prima di immergerci nel buildout.cfg, diamo un veloce sguardo alle cartelle che buildout ha creato per noi:

bin/

Contiene vari eseguibili, inclusi il comando buildout, e lo script di controllo dell'istanza Zope.

eggs/

Contiene egg che buildout ha scaricato. Queste saranno attivate esplicitamente dallo script di controllo nella cartella bin/ .

downloads/

Contiene download non-egg, come l'archivio del codice sorgente di Zope.

var/

Contiene i file di log (in var/log/) e il file di storage dei dati dello ZODB (in var/filestorage/Data.fs). Buildout non li sovrascriverà mai.

src/

Inizialmente vuoto. Puoi mettere qui le tue egg di sviluppo e referenziarle in buildout.cfg. Altro su questo più avanti.

products/

Analoga alla cartella Products/ di una istanza Zope (nota la differenza nella lettera maiuscola). Se stai sviluppando un qualsiasi prodotto nel vecchio stile Zope 2, sistemalo qui. Vedremo come buildout può automaticamente scaricare e gestire archivi di prodotti, ma se vuoi estrarre la dipendenza di un prodotto manualmente, o da Subversione, questo è il posto per farlo.

parts/

Contiene codice e dati gestiti da buildout. Nel nostro caso includerà l'installazione locale di Zope, una istanza Zope gestita da buildout, e il codice sorgente di Plone. In generale non dovresti modificare nulla in questa cartella, perchè buildout potrebbe sovrascrivere i tuoi cambiamenti.

Puoi effettuare il check in di una cartella buildout verso un repository di codice sorgente per condividerlo tra gli sviluppatori. In questo caso, dovresti ignorare le cartelle bin/, eggs/, downloads/, var/, and parts/. Ogni sviluppatore può eseguire bootstrap.py per riaverle di nuovo, e normalmente avrà bisogno di copie locali in ogni caso. Tutte le tue configurazioni dovrebbero stare nel file buildout.cfg, e tutto il codice personalizzato in src/ o products/.