Wir sind nun startklar, um ein neues Buildout zu erstellen. Das "Buildout" ist ein Verzeichnis, das alle Teile, die ein Projekt ausmachen, enthält, einschließlich einer Zope-Instanz, den Plone-Quelltexten, kundenspezifischen Konfigurationsoptionen und den Quelltext Ihres Projektes. Erstellen Sie einen etwa wie dies:

 $ paster create -t plone3_buildout myproject     
   

Dies wird Sie Ihnen eine Serie von Fragen stellen. Falls Sie eine existierende Installation von Zope benutzen wollen, statt Buildout eine herunterladen und für Sie kompilieren zu lassen, bestimmen Sie einen absoluten Pfad als den zope2_install. Wenn Sie nicht wollen, dass Buildout die Kernprodukte von Plone herunterlädt, können Sie es in gleicher Weise auf ein existierendes Verzeichnis hinweisen, das alle Produkte enthält (es wird dennoch Plones Eier (Eggs) herunterladen, aber - wie wir später sehen werden - ist es möglich, ein Ei-Verzeichnis (egg directory) von mehreren Buildouts benutzen zu lassen). Sie werden einen Benutzernamen und ein Passwort für den Zope-Administrator eingeben müssen und Sie wollen eventuell den Debug-Modus und die wortreiche Sicherheit anstellen wollen während der Entwicklung.

Gehen Sie nun in das neu erstellte Verzeichnis myproject und starten Sie das Buildout-Bbootstrap-Skript:

 $ cd myproject     
 $ python bootstrap.py     
   

Dies wird eine Anzahl von Verzeichnissen und Skripten erstellen und die neueste Version von dem Ei zc.buildout herunterladen. Dieser Schritt sollte nur einmal nötig sein.

Um sofort anzufangen, lassen Sie folgendes laufen:

 $ ./bin/buildout   

Dies liest die erstellte Datei buildout.cfg und führt seine verschiedenen "Teile" aus, Zope installieren, eine Zope-Instanz erstellen, Plone herunterladen und Installieren. Wir werden diese Datei gleich detaillierter erläutern.

Sie müssen ./bin/buildout zu jeder Zeit erneut ablaufen lassen, wenn Sie buildout.cfg verändert haben. Falls Sie nicht wollen, dass Buildout online geht und nach aktualisierten Versionen von Eiern (eggs) sucht oder andere Archive herunterlädt, können Sie es in einem Nicht-Aktualisierungs- oder Offline-Modus laufen lassen mit folgendem Kommando:

 $ ./bin/buildout -No     
   

Um Zope zu starten, lassen Sie folgendes laufen:

 $ ./bin/instance fg     
   

Das Skript  instance analog zu zopectl, wie man es in der Standard-Zope-Instanz findet. Sie können ./bin/instance start benutzen, um Zope im Dämon-Modus (als Dienst) laufen zu lassen. Es kann verwendet werden, um Tests laufen zu lassen:

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

Verzeichnisse in dem Buildout

Bevor wir in buildout.cfg eintauchen, lassen Sie uns einen kurzen Blick auf die Verzeichnisse werfen, die Buildout für uns erstellt hat:

bin/

Enthält verschiedene ausführbare Dateien, einschließlich dem Kommando buildout und dem Zope-Kontroll-Skript der Instanz .

eggs/

Enthält Eier (eggs), die Buildout herunter geladen hat. Diese werden ausdrücklich aktiviert von dem Kontrollskript in dem Verzeichnis bin/.

downloads/

Enthält Nicht-Ei-Downloads (non-egg downloads) wie zum Beispiel das Zope-Quelltextarchiv.

var/

Enthält die Protokolldateien (log files) (in var/log/) und die Datenspeicherdatei ZODB (in var/filestorage/Data.fs). Buildout wird diese niemals überschreiben.

src/

Anfangs leer. Sie können Ihre eigenen Entwicklungs-Eier (development eggs) hier platzieren und sie in buildout.cfg referenzieren. Mehr dazu später.

products/

Dies ist analog zum Verzeichnis Products/ (beachten Sie den Unterschied der Großschreibung) einer Zope-Instanz. Falls Sie irgendwelche Zope-2-Produkte alten Stils entwickeln, platzieren Sie diese hier. Wir werden sehen, wie Buildout Produktarchive automatisch herunterladen und verwalten kann, allerdings, falls Sie eine Produktabhängigkeit manuell auswählen wollen oder aus Subversion auschecken wollen, ist dies der Platz, es zu tun.

parts/

Enthält von Buildout verwalteten Programmcode und Daten. In unserem Fall wird es die lokale Zope-Instanz einschließen, eine Buildout-Verwaltete Zope-Instanz, und den Quelltext von Plone. Im allgemeinen sollten Sie nichts in diesem Verzeichnis verändern, da Buildout eventuell Ihre Änderungen überschreibt.

Sie können in einem Buildout-Verzeichnis gegen ein Quellcode-Repository checken, um es unter Entwicklern gemeinsam zu nutzen. In diesem Fall sollten Sie die Verzeichnisse bin/, eggs/, downloads/, var/ und parts/ nicht beachten. Jeder Entwickler kann bootstrap.py laufen lassen und diese Verzeichnisse zurückbekommen und wird wie auch immer normalerweise nur lokale Kopien benötigen. All Ihre Konfiguration sollte sich in der Datei buildout.cfg befinden und aller angepaßter Programmcode in src/ oder products/.