Dokumentu Akzioak
Blog de erral
Buildout reloaded
Hace unos meses escribí sobre buildout. Desde entonces ha habido muchos avances en ese mundo, incluyendo un excelente tutorial de Martin Aspeli sobre el tema.
- ¿Cuántas veces has subido una versión de un producto al servidor, has arrancado zope y ha explotado?
- ¿Cuántas veces se te ha olvidado subir ese producto que sólo cambias de pascuas a ramos?
- ¿No sería mejor, que en vez de documentar la instalación y guardar esa documentación (con los problemas que tienes luego de tener que actualizar tanto la instalación como la documentación), la propia documentación sirviera como guión para instalar nuestra aplicación?
¿Qué es buildout?
Es una forma declarativa de declarar (valga la rebuznancia) qué es lo que va a tener tu aplicación (en nuestro caso la aplicación será una instancia de Plone):
- Plone 2.5.3 y por lo tanto su correspondiente Zope.
- Que tenga instalados unos productos que estoy desarrollando yo en mi svn privado
- Que tenga instalados unos productos desde un svn público
Eso es muy bueno, ¿cómo lo hago?
Primero creamos una carpeta llamada 'mibuildout', en el que ponemos el archivo bootstrap.py. Posteriormente creamos en esa misma carpeta un archivo de configuración llamado 'buildout.cfg'. El contenido del archivo 'buildout.cfg' será el siguiente:
[buildout]
parts =
plone
zope2
otherproducts
svnproducts
prepproducts
instance
find-links =
http://dist.plone.org
http://effbot.org/downloads
eggs =
itools >=0.9 <0.10
develop =
[plone]
recipe = plone.recipe.plone25install
url = http://plone.googlecode.com/files/Plone-2.5.3-final.tar.gz
[zope2]
recipe = plone.recipe.zope2install
url = http://www.zope.org/Products/Zope/2.9.8/Zope-2.9.8-final.tgz
[otherproducts]
recipe = plone.recipe.distros
urls =
http://www.codesyntax.com/bitakora/Bitakora-0.1.10.tgz
http://hathawaymix.org/Software/CookieCrumbler/CookieCrumbler-1.2.tar.gz
http://download.ikaaro.org/localizer/Localizer-1.1.0.tar.gz
http://download.ikaaro.org/ihotfix/iHotfix-0.7.0.tar.gz
http://iungo.org/products/Epoz/releases/Epoz-2.0.2.tar.gz
nested-packages =
version-suffix-packages =
Localizer-1.1.0.tar.gz
iHotfix-0.7.0.tar.gz
[svnproducts]
recipe = plone.recipe.bundlecheckout
url = http://svn.plone.org/svn/collective/Quills/bundles/1.5-zope29
[preproducts]
recipe = plone.recipe.command
command = cd ${otherproducts:location}/TextIndexNG2 && ${buildout:executable} setup setup.py install
[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
http-address = localhost:8080
user = admin:admin
eggs =
${buildout:eggs}
products =
${plone:location}
${otherproducts:location}
${svnproducts:location}
Ahora solo nos queda invocar el buildout:
$ python2.4 bootstrap.py
$ ./bin/buildout -v
Ya tenemos en marcha una nueva y reluciente instancia, con Plone, Bitakora, Quills y todo lo que hemos puesto en el archivo de configuración.
Pero... ¿cómo demonios?
Vayamos por partes, como dijo Jack el Destripador. Un buildout se compone de diferentes partes que se indican en la variable 'parts'. Por cada parte buildout creará una carpeta del mismo nombre dentro de la carpeta 'parts'.
En la variable eggs, le indicamos unos huevos o librerías Python que queremos que instale. buildout es inteligente, e irá al PyPI a por ellos. En este caso le hemos dicho que se descargue la librería itools, pero una versión entre la 0.9 y la 0.10 (es un requisito de Localizer).
Tras la configuración general del buildout, sólo nos queda indicarle qué hacer en cada parte, por lo que tenemos una sección de configuración por cada parte. Todas las partes tienen una variable llamada 'recipe' que indica que receta se debe utilizar para instalar dicha parte. Cada receta es diferente, e intentaré explicar lo que hace cada una de las utilizadas aquí
plone.recipe.plone25install
Como su propio nombre indica (¿esto es autosignificante Nando?), se descarga Plone 2.5.3 desde la URL que se indica en url y lo descomprime.
plone.recipe.zope2install
Descarga Zope desde la URL indicada en url, lo compila e instala
plone.recipe.distros
Descarga los archivos indicados desde las URL indicadas y los descomprime. Además si alguno de los paquetes contiene otros archivos (se me ocurre por ejemplo el Localizer Metapackage), los extrae al sitio adecuado (hay que indicarle cuales utilizando la variable 'nested-packages'). Si además, cuando descomprimes los archivos, las carpetas que se crean tienen un sufijo indicando la version (al estilo Localizer-1.0.1), si se lo indicas en 'version-suffix-packages', buildout se encarga de ajustar el nombre.
plone.recipe.bundlecheckout
Descarga los archivos de un svn a partir de la url
plone.recipe.command
Ejecuta un commando arbitrario
plone.recipe.zope2instance
Instala una instancia zope2, utilizando el zope instalado en la parte zope2 y añadiéndole como path de los productos que tienen que cargar todos los que le añadimos en la variable products.
¿Y ahora qué?
Ahora que sabemos cómo utilizar un buildout, sólo nos falta crear nuestro buildout.cfg, en el que documentamos todas las versiones de los productos que vamos a instalar, y guardarlo en un svn, para poder llevar el registro de cambios que le hagamos (nuevas versiones, ...) y poder replicar fácilmente la configuración de la máquina de desarrollo en la máquina de producción.
Mi próximo proyecto Plone lo gestionaré con un buildout como este (lo que también facilitará la tarea de poder utilizar nuevas librerías para plone escritas en forma de huevos.
Preguntas, dudas, comentarios, ...
Estoy abierto a cualquier tipo de pregunta o consulta sobre buildout, ¡déjame un comentario!
Actualización: Acabo de hacer la prueba y también funciona en Windows !!!
http://dukebody.com
Estoy intentando utilizar cosas de www.plone-es.org como los comentarios pero salta un error (del que yo no puedo conseguir un traceback, claro) y el formulario de contacto tampoco funciona, dice algo de "Dominio no encontrado". No sé si tú tienes contacto con los administradores del sitio, pero si lo tienes te agradecería que les avisases, por favor.