Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Thursday, January 28, 2010

Desarrollando con zc.buildout

En un post anterior comentaba que es zc.buildout, por qué puede necesitarlo un desarrollador y como instalarlo. Ahora hablaré sobre como desarrollar un proyecto usandolo.

buildout.cfg

buildout.cfg es el archivo que determina como se construirá el proyecto, cuales son sus partes y como generarlas. El formato del archivo es el tradicional .INI de windows, dividido en secciones (nombres encerrados entre corchetes) formadas por lineas con el formato clave=valor.
[buildout]
develop = .
parts = dependencias

[dependencias]
recipe = zc.recipe.egg:eggs
eggs = python-ldap
docutils
La sección buildout es la única requerida en el archivo buildout.cfg. La primera linea
develop = .
indica cuales son los directorios con los paquetes de desarrollo (los paquetes o huevos en los que estamos trabajando y que todavía no hemos instalado). Cada uno de esos directorios debe tener un archivo setup.py que defina el huevo de python.
parts = dependencias
dice que este proyecto esta formado por una única parte, llamada "dependencias". Cada parte deberá tener su propia sección donde se indique como construirla. En nuestro ejemplo
[buildout]
develop = .
parts = dependencias

[dependencias]
recipe = zc.recipe.egg:eggs
eggs = python-ldap
docutils
zc.recipe.egg es un paquete que define un récipe con nombre eggs . Este recipe es un programa encargado de construir la parte dependencias. Lo que hace este recipe en particular es descargar los paquetes python-ldap y docutils. Nota que una linea que comienza con espacios significa que es la continuación de la linea anterior.

Así como hay récipes para instalar los paquetes o huevos de python, hay otros que instalan aplicaciones en C, como openldap o postgresql o para descargar proyectos vía CVS o git. El python package index tiene una larga lista de paquetes con récipes para zc.buildout.

Cuando hayas terminado con buildout.cfg puedes construir todas las dependencias de tu sistema con un simple comando:
{ ubicado en la raiz de tu proyecto}
$ bin/buildout
Deberas ejecutar buildout cada vez que agregues una nueva dependencia y hayas editado buildout.cfg. Pero lo más importante es que tus usuarios también podrán instalar todas las dependencias de tu aplicación ejecutando buildout.

Esto es todo lo que hay que saber de zc.buildout para usarlo en tus desarrollos. El resto es buscar las recetas que generen las partes que necesites. En última instancia, un récipe es simplemente un script en python, por lo que puedes crear uno nuevo si no consigues ninguno que satisfaga tus necesidades.

Thursday, January 21, 2010

zc.buildout

Comienzo hoy una serie de artículos sobre desarrollo de aplicaciones en python, particularmente, desarrollo web. Y nuestro invitado del día es zc.buildout. O simplemente buildout, para los amigos.

A buildout lo había mencionado de pasada en otras oportunidades. Ahora es el momento de tratarlo con exclusividad, como se merece.

Que problema soluciona buildout?

Desarrollar una aplicación para distribuirla tiene una serie particular de problemas. Los equipos donde se instale pueden no tener todas las aplicaciones de las que esta depende. O pueden tener versiones viejas o incompatibles. Este problemas se agrava cuando desarrollamos en un lenguaje de scripts. Aquí las dependencias suelen ser librerías desarrolladas con ese mismo lenguaje. Tristemente, ninguna distribución puede ofrecer una versión actualizada de todos los proyectos hechos en python, perl o ruby.

Esta situación le deja al programador (es decir a ti) la necesidad de hacer que el instalador de su aplicación busque e instale todas las dependencias, en sus versiones correctas. Esto distrae al programador de su tarea real: desarrollar la mejor aplicación posible.

Y precisamente este es el trabajo de buildout: asegurarse de conseguir e instalar todas las piezas de software que tu aplicación necesita.

Como funciona

Buildout se encarga de ensamblar todas las partes que necesita tu aplicación. Esto lo logra esto a traves de un lenguaje declarativo y extensible. Una serie de "recetas" pre-establecidas resuelven los problemas típicos del manejo de dependencias. Así que en la mayoría de los casos basta con indicarle tus necesidades y buildout se encargará en resolverlas.

La parte extensible entra en juego cuando tu aplicación necesita algo inusual. Entonces programas una nueva receta (en python) que resuelva esa dependencia y listo. El mundo tiene una nueva receta de buildout que puede ser usada por otros desarrolladores y cada día el trabajo con buildout se facilita.

Ejemplo práctico

El primer paso es, desde luego instalar buildout:
$ sudo easy_install zc-buildout
En otro post comenté como instalar easy_install. Buildout depende exclusivamente de easy_install y es todo lo que el desarrollador necesita para manejar el problema de las dependencias. Sin embargo, el usuario final podría no tener instalado zc-buildout, por lo cual el recomendable agregar a tu proyecto un pequeño script que se encargue de conseguirlo:
# Bajamos bootstrap
$ wget 'http://svn.zope.org/*checkout*/buildout-website/trunk/bootstrap.py'

# Y lo guardamos en un lugar seguro para
#agregarlo
a cada poyecto que use buildout
$ mv bootstrap.py ~/bin

Ok, ya tenemos instalado buildout y bootstrap, ahora solo necesitamos un proyecto en python:
# Creamos nuestro nuevo proyecto
$ mkdir miproyecto
$ cd miproyecto

# Inicializamos buildout
$ buildout init

# ...y copiamos bootstap.py para
# beneficio de nuestros usuarios

$ cp ~/bin/bootstrap.py .

Esto creará los siguientes objetos en nuestro directorio:
bin/
develop-eggs/
eggs/
parts/
buildout.cfg
En bin/ esta una copia de buildout. Aquí se instalarán los comandos de todos los huevos (paquetes en python) que instalemos.

develop-eggs/ es un directorio manejado por buildout y que no necesitamos tocar directamente. Aquí habrá un enlace simbólico a cada paquete en desarrollo que necesitemos. Un paquete en desarrollo es, como su nombre lo indica, un paquete sobre el cual estamos trabajando todavía. Los paquetes en desarrollo no están instalados en el sistema y normalmente son inaccesibles a otros paquetes. Es por eso que buildout les ha dedicado todo un directorio: para poder acceder a ellos sin necesidad de instalarlos.

En eggs/ irán todos los paquetes o huevos de los que nuestra aplicación necesite. De nuevo, buildout los bajará por nosotros y verificará en cada ocasión, de ser necesario, que estén en su última versión.

parts/ es usado por los récipes. Aquí es donde se compilará, por ejemplo, una aplicación en C, que necesite nuestra aplicación.

Cuando empaquetemos nuestra aplicación, el programa empaquetador de python (setuptools) creará otros directorios, no relacionados con buildout.

Finalmente, está el archivo buildout.cfg. Para nosotros como desarrolladores, este es el corazón de buildout. Aquí indicaremos todas las instrucciones necesarias para que nuestra aplicación encuentre un entorno donde pueda correr sin problemas. Indicaremos cuales librerías en python necesita, y si estas son estables o no. Le diremos que aplicaciones en C, C++ u otro lenguaje tendrá que descargar, compilar e instalar, si ese fuera el caso. Le diremos si necesitamos crear una base de datos y cual debe ser su contenido. En fin, buildout.cfg nos dice todo lo que necesitamos saber de las dependencias de nuestra aplicación.

El contenido de buildout.cfg lo trataré en la próxima entrega.

Monday, January 18, 2010

Ya salió el libro de repoze.bfg

Ya salió el libro de repoze.bfg, el interesante entorno de desarrollo en python+WSGI. repoze.bfg es un framework minimalista inspirado en zope. Comparativamente ofrece las siguientes ventajas:
  • Fácil de entender: Al ser un framework pequeño, puede ser entendido con menor esfuerzo.
  • Familiaridad: Si ya has programado en zope, repoze.bfg es el paraíso: es zope2 bien hecho.
  • Usa WSGI: Lo cual le permite interoperar más fácilmente con otras aplicaciones (aunque la última versión de zope parece que vendrá por defecto para usar WSGI).
  • Pagas solo por lo que comes: Viene sin soporte para base de datos, autenticación, autorización o manejo de sesión. Toda esta funcionalidad esta soportada por proyectos independientes.
  • Rápido: Dado que las aplicaciones desarrolladas en bfg no contienen componentes innecesarios, su velocidad de respuesta aumenta.
Desde luego, bfg también tiene sus inconvenientes respecto a zope. Y como suele suceder, algunas de sus características positivas tienen su lado negativo:
  • No TTW: Zope2 ganó una inmensa popularidad al permitir el desarrollo de aplicaciones a través del web. bfg es un framework para programadores exclusivamente.
  • Pocos componentes integrados: Fiel a su idea original de minimalismo, es responsabilidad del programador decidir sobre los componentes básicos de su aplicación. Cada vez. Por cada componente. Incluso en las pruebas más triviales.
En definitiva, repoze.bfg dará que hablar. Este framework tiene el potencial para desarrollar el sucesor de Plone.

Tuesday, August 5, 2008

Autenticacion LDAP en zope2

La autenticación LDAP en zope2 se ha hecho mas fácil con los eggs. Basta con agregar al listado de eggs necesarios en buildout el nombre Products.PloneLDAP.
Este producto depende a su vez de
  • python-ldap
  • LDAPUserFolder
  • LDAPMultiPlugins
todos ellos descargados automáticamente durante el buildout.

Ahora, Centos 4 viene con una versión antigua de LDAP que no es compatible con python-ldap. Para compilar este paquete hay que instalar ldap-2.3 en paralelo con la versión de la distro. Una vez hecho esto hay que bajar y generar una versión local del egg python-ldap, que se enlace las nuevas librerías:
# Bajar solamente el egg
$ easy_install -b downloads/ python-ldap
$ cd downloads/python-ldap
Luego se edita el archivo setup.cfg cambiando las variables library_dirs e include_dirs para que apunten al directorio de librerías e includes de la nueva versión de LDAP. Una vez hecho esto, se genera el egg
$ ./setup.py bdist_egg

Este egg puede luego ser copiado en el directorio egg de la instancia a desarrollar.

Para activar la autenticación LDAP, desde la interface ZMI del zope se visita la carpeta acl_user del sitio plone. En ella se cre un 'Plone LDAP Plugin', digamos con el nombre ldapmaster. Luego todas sus funcionalidades deben ser activadas (site/acl_users/ldapmaster lengüeta "activate"). Finalmente hay que prioritizar el uso de la autenticación ldap, visitando site/acl_users/plugins, seleccionando primero el Plugin Type "Properties Plugins" y poniendo de primero a ldapmaster. Luego se hace lo propio "UserManagement Plugins".

Desarrollo y Despliegue en zope2+Plone3

A continuación sigue como desarrollar y desplegar un sitio basado en zope 2 y Plone 3 usando egg.

Instalar el entorno virtual

Como siempre comenzamos instalando un entorno virtual para trabajar con comodidad

# con una version previa de easy_install, instalar virtualenv
$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python2.4 ez_setup
$ sudo easy_install-2.4 virtualenv

# crear el entorno virtual de python

# y comenzar a trabajar en el
$ virtualenv ~/entorno
$ cd ~/entorno
$ source bin/activate

Instalación del Zope 2 y Plone 3

Luego instalamos ZopeSkel, que nos generará un buildout.cfg que se adaptará al tipo de proyecto de zope2 que querramos:
$ easy_install ZopeSkel

Podemos ver que clase de proyectos podemos crear con ZopeSkel del siguiente modo:
$ paster create --list-templates

Luego creamos el proyecto zope2+plone3 propiamente, hacemos el bootstrap y el buildout:
$ paster create -t plone3_buildout myPlone
$ cd myPlone
$ python bootstrap
$ bin/buildout
Posteriormente podremos usar la opción -No en el buildout para que no chequee que cada egg bajado tenga la última versión.

Para arrancar el zope:
$ bin/instance fg

Despliegue

Como ya es costumbre, los productos que deseemos agregar a nuestra instancia se agregan a la variable egg de buildout.cfg y se vuelve a reconstruir el proyecto. Si el producto tiene algún archivo de configuración zcml, este debe ser agregado en la sección zcml.

Los eggs de desarrollo deben ser registrados tanto en eggs, como en la variable develop.

Desarrollo

Para desarrollar un egg, se usa de nuevo paster en el directorio src de la instancia en cuestion:
$ paster create -t plone mi.producto

Como siempre las dependencias de este producto van en su setup.cfg.

Thursday, February 21, 2008

Desarrollo y Despliegue en zope

Siguiendo con los apuntes de zope 3, aquí esta la versión aumentada y corregida de como trabajar con zope. Básicamente se quiere llevar a cabo dos actividades: desarrollo (development) y despliegue (deployment).

Preconfiguración

Antes de desarrollar cualquier aplicación es conveniente tener un entorno sano y reproducible y de preferencia trabajar en un sandbox personal. Ya vimos una opción para crear este entorno virtual usando virtual-python. El sucesor de virtual-python es virtualenv. Esta aplicación funciona mejor que virtual-python en windows y genera un entorno menos polucionado. Además, instala automaticamente easy_install y un script de activación del entorno:
# con una version previa de easy_install, instalar virtualenv
$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python2.4 ez_setup
$ sudo easy_install-2.4 virtualenv

# crear el entorno virtual de python

# y comenzar a trabajar en el
$ virtualenv ~/entorno
$ cd ~/entorno
$ source bin/activate

# instalar zope-project
$ easy_install zopeproject

# instalar zc.buildout

$ easy_install zc.buildout
El ultimo comando se encarga de fijar algunas variables de entorno, modificar el path para usar el interprete de python del entorno virtual y modificar el prompt para indicar que el entorno esta activo.


Despliegue

El despliegue es la creación y configuración del sitio web propiamente. Para crear el sitio de despliegue (una instancia de zope 3) usamos zopeproject dentro de nuestro entorno virtual previamente activado:
# Crear una instancia
$ zopeproject misitio
{introducir el login del administrador}
{introducir la contraseña del administrador}
{introducir la ruta donde se guardarán los eggs para el proyecto
indicar preferiblemente ~/entorno/lib/python2.4/site-packages/ }

# comenzar a trabajar en el sitio de despliegue
$ cd misitio
El sitio se configura en src/misitio/sonfigure.zcml y sus dependencias para la generación del egg se especifican en setup.py, como de costumbre. El script para el buildout es buildout.cfg.

Como siempre, al agregar o eliminar dependencias, se debe correr bin/buildout.


Desarrollo

El desarrollo es la creación de paquetes para zope. Estos paquetes normalmente no tienen utilidad fuera del zope, sino que son las piezas de lego con las que se construye un sitio. Es conveniente que cada paquete de desarrollo resida en su propio directorio y sus requerimientos sean manejados por zc.buildout. Ahora se creará la estructura mínima de un paquete de desarrollo, siempre en el entorno virtual previamente activado:
# Crear el directorio para el buildout del paquete
$ mkdir mipaquete
$ cd mipaquete
$ buildout init

# Crear la estructura mínima del buildout
$ touch setup.py
$ mkdir -p src/mipaquete
$ touch src/mipaquete/__init__.py
La estructura básica de buildout.cfg es
[buildout]
develop = .
parts = test
eggs-directory = /home/jdinunci/apps/webdev/lib/python2.4/site-packages/
{ruta donde yo guardo los eggs}

[test]
recipe = zc.recipe.testrunner
eggs = mipaquete [test]


La estructura básica de setup.py es
import os
from setuptools import setup, find_packages

def read(*rnames):
return open(os.path.join(os.path.dirname(__file__), *rnames)).read()

setup (
name='mipaquete',
version='0.1',
author = "Jose Dinuncio",
author_email = "micorreo@midominio.org",
description = "Mi paquete",
license = "GPL",
keywords = "zope3",
classifiers = [
'Environment :: Web Environment',
'Intended Audience :: Developers',
'Programming Language :: Python',
'Natural Language :: English',
'Operating System :: OS Independent',
'Topic :: Internet :: WWW/HTTP',
'Framework :: Zope3'],
packages = find_packages('src'),
include_package_data = True,
package_dir = {'':'src'},
# linea de abajo solo necesaria para
# paquetes virtuales
#namespace_packages = ['reduc'],
extras_require = dict(
test = [
'zope.testing',
'zope.app.container [test]',
],
),
install_requires = [
'setuptools',
'zope.interface',
'ZODB3',
'zope.schema',
'zope.app.container',
'zope.app.content',
'zope.dublincore',
],
dependency_links =
['http://download.zope.org/distribution'],
zip_safe = False,
)

En mi caso, mis paquetes usan paquetes virtuales, por lo que suelen llamarse reduc.mipaquete, lo cual implica ligeras modificaciones en el procedimiento
#Crear el directorio para el buildout del paquete
$ mkdir reduc.mipaquete
$ cd reduc.mipaquete
$ buildout init

# Crear la estructura mínima del buildout
$ touch setup.py
$ mkdir -p src/reduc/mipaquete
$ touch src/reduc/mipaquete/__init__.py

# Crear el paquete virtual reduc
$ echo "__import__('pkg_resources').declare_namespace(__name__)"
> src/reduc/__init__.py
En este caso, hay que agregar una configuración a setup.py para el manejo del paquete virtual:
namespace_packages = ['reduc'],

Estos paquetes en desarrollo pueden ser incluidos en el sitio de despliegue con la directiva develop

[buildout]
develop = .
../mipaquete

Al ejecutar bin/buildout, se crea un enlace en develop-egg que permite que los paquetes sean encontrados.

Este es el ciclo depurado para el desarrollo y despliegue en python. Aún puede agregarse mas comodidad al mismo, como agregar al buildout la descarga automatica de paquetes de desarrollo vía svn.

Friday, February 15, 2008

Como obtener paquetes de Zope via svn

Lo ideal es obtener los paquetes de zope vía easy_install o buildout. Sin embargo, una importante cantidad de paquetes es estado de desarrollo, pero aún estables, se encuentran en un repositorio de subversion.

La primera pregunta es: ¿Como saber que hay en ese repositorio? Una forma fácil es visitando http://svn.zope.org. Supongamos que eliges http://svn.zope.org/z3c.weblog/. Después de ubicar el paquete en cuestión, es solo cosa de descargando usando el svn, mas con la siguiente salvedad: se sustituye el protocolo por svn y se prefija la url con repos/main/:

svn co svn://svn.zope.org/repos/main/z3c.weblog z3c.weblog
Una vez hecho esto, se debe generar el entorno para el buildout y ejecutar el buildout propiamente:
# bootstrap
# bin/buildout
O, si ya se dispone de un buildout, simplemente invocarlo.

Friday, February 1, 2008

Desarrollando con zc.buildout

Siguiendo con el desvío tomado en Huevos y Constructores, abordaremos el desarrollo de paquetes en python usando zc.buildout. La instancia de zope que creamos con zopeproject es un proyecto manejado por buildout, por lo que es de suma importancia entender como funciona este de manera aislada. Para ello crearemos un paquete en python con una implementación de ejemplo.

Por que usar buildout? Dado que queremos hacer fácilmente instalable nuestro paquete por terceras personas, requerimos algún método para empaquetarlo y distribuirlo. Podríamos usar distutil, pero durante el desarrollo con cada cambio hecho al código deberiamos generar la distribución e instalarla antes de hacer una prueba. Adicionalmente, para hacer la instalación se requiere permisología de root.

Otras ventajas de builtout sobre distutils es que este usa setuptools, por lo que podemos resolver los problemas de dependencias y versiones con los que se enfrentaría quien tratara de instalar el paquete. buildout se ocupa además de preconfigurar el paquete antes de hacer la instalación o pruebas.

Para instalar zc.buildout se requiere setuptools y se recomienda virtual-python (veáse Instalando Zope 3).

Para procesar un paquete o aplicación con buildout se requiere un archivo buildout.cfg que defina el entorno que el paquete necesita:
[buildout]
develop=.
...
La estructura del archivo buildout.cfg es una serie de secciones cuyo nombre aparece entre corchetes, seguida por una serie de pares clave=valor que definen la sección. [buildout] es la sección principal y la única requerida.

buildout.cfg define una serie de partes o elementos necesarios para que la aplicación funcione. Cada parte se define en una sección diferente. Cada parte es procesada por un recipe (un programa en python para instalar y actualizar la parte). Las demas lineas de una sección sirver para configurar el recipe. Hay una gran variedad de recipes para distintas funciones, como descargar eggs, compilar aplicaciones, correr la batería de pruebas de un paquete,e tc. En caso de necesidad el desarrollador puede crear sus propios recipes.


Desarrollando un paquete con buildout


Comenzamos desarrollando un paquete normal en python
# mkdir blah
# cd blah

# mkdir src {aquí va el código fuente de los paqutes a desarrollar}
# mkdir src/blah
# ... {se agregan los módulos al paquete blah}
Este paquete será distribuido con setuptools, por lo que debemos crear un archivo blah/setup.py que defina su distribución:
# blah/setup.py
from setuptools import setup, find_packages

setup(name='blah',
version='0.1',
packages=find_packages("src"),
package_dir={"": "src"},
# Notese que los requisitos del paquete son indicados
# aquí para que setuptools pueda generar
# correctamente su egg

install_requires=[ 'zope.tal' ], )
Hasta este punto tenemos un paquete convencional de python, listo para ser distribuído via setuptools. Ahora hay que convertir el directorio de trabajo en un directorio manejado por buildout.

Ahora, se define el archivo buildout.cfg que determinará como generar la aplicación
[buildout]
develop=.
parts=me

[me] recipe=zc.recipe.egg
eggs=zope.tal
Este archivo define una parte llamada 'me', la cual para ser construida requiere el recipe encargado de descargar eggs. El único egg a descargar será zope.tal.

Pero aún falta en manejar este proyecto a traves de buildout. Para crear la infraestructura necesaria, hay que hacer un bootstrap. Este procedimiento se realiza una única vez en la vida del proyecto:
# ruta-hacia-buildout/buildout bootstrap

(Desde luego, buildout debe estar instalado, cosa fácil gracias a easy_install).

buildout creará un directorio bin donde instalará su ejecutable y cualquier otro requerido por las dependencias. Creará además un directorio eggs donde instalará los eggs necesarios por esta aplicación, un directorio develop-eggs donde creará referencia a los eggs que esta aplicación defina y un directorio parts, para ser utilizado por las partes del archivo de configuración.

Ya con toda la infraestructura en su lugar, para asegurar que la aplicación tenga todos sus requerimientos instalados basta con ejecutar
# buildout
Con cada cambio en las dependencias es necesario re-ejecutar el comando, para que satisfaga las nuevas necesidades de la aplicación.

Jugando con las partes y los recipes se puede automatizar el proceso de instalación de las dependencias de la aplicación. Otras funciones determinan si se descargará la versión mas nueva de un paquete o una en especifico.

Se puede generar la distribución de los paquetes por medio de setuptools o por medio de buildout. En el último caso, los comandos son:
# bin/buildout setup . sdist {distribución fuente}
# bin/buildout setup . bdist {binarios}

# bin/buildout setup . bdist_egg {bnarios en eggs}
La fuente autoritativa de zc.buildout se encuentra en http://pypi.python.org/pypi/zc.buildout

Huevos y Constructores

Antes de proseguir con el desarrollo en zope es conveniente tomar un desvío hacia dos tecnologías usadas por zope que pueden no ser conocidas por los desarrolladores en python: los eggs y buildout.


Los eggs son una forma conveniente de distribuir paquetes de python. Pueden pensarse como el equivalente a los .jar de java, solo que con mayor riqueza. Los eggs son una extensión al mecanismo tradicional de distribución de paquetes en python, ofrecido por distutils.

distutils es la herramienta incorporada en python para la compilación e instalación de paquetes. Normalmente el usuario descarga un archivo .tgz con la fuente del paquete, lo descomprime y ejecuta el archivo setup.py que este contiene. setup.py invoca a distutils que compila (de ser necesario) e instala el paquete en un lugar donde pueda ser encontrado por python.

Los eggs mejoran este proceso. Son paquetes ya compilados, por lo que no requieren herramientas de desarrollo adicionales (compiladores, etc). Pueden estar comprimidos, siendo mas fácilmente manipulables. Además, ofrecen una metadata mas rica, lo cual permite la detección de dependencias.

Esta última característica es lo que permite usar eggs para construir un repositorio de aplicaciones con instalación simplificada. El programa easy_install.py se aprovecha estas características para permitir una instalación de las aplicaciones y sus dependencias con una simple instrucción.

El crear un egg es tan simple como crear un paquete con distutils. Solo se necesita tener instalado el paquete setuptools (el cual es en si mismo un egg que puede ser instalado automáticamente por easy_install). Si el egg va a ser distribuido empaquetado como un zip, entonces debe seguirse unas convenciones adicionales.


La otra tecnología es buildout. El término en general se refiere a todo lo necesario para la construcción e implementación de una aplicación. Cuando un desarrollador esta trabajando en una aplicación con muchas dependencias, necesita herramientas para automatizar su configuración y seguir las versiones de cada paquete usado. La gente de zope desarrolló el paquete zc.buildout con esta finalidad.

zc.buildout permite crear entornos para el desarrollo que sean fácilmente repetibles. De esta manera, el desarrollador podrá trabajar con frameworks complejos como zope y trasladar su trabajo a otro equipo. El resultado final de zc.buildout es un egg con la información exacta de todas las dependencias, versiones y todos sus procesos de configuración. Al instalar este egg en un tercer equipo se obtendrá una copia exacta del entorno en el equipo original.

El ingrediente final en la entrada anterior fue el paquete zopeproject. Este paquete instala un comando del mismo nombre que genera un buildout preconfigurado para iniciar un proyecto con zope.

En entradas posteriores trataré el uso de los eggs y de zc.buildout en desarrollos de python independientes de zope para mostrar su utilidad general. Esto permitirá comprender de forma mas fácil que su uso en zope es conveniente mas dispensable.