Instalando, Configurando y Ejecutando OpenERP 5 (openerp-server y openerp-web) en CentOS 5 64 bits

2009·DIC·05, ed. 2010·JUN·21 © Javier de Lorenzo-Cáceres · Derechos Reservados.

Introducción

Documentación oficial

La documentación oficial sobre la instalación de Open ERP, muy orientada a Ubuntu con apenas unas referencias a Fedora y Mandriva, es la siguiente:

• Manual de Instalación (en inglés): http://doc.openerp.com/install/index.html#installation-link
• Primer capítulo del Manual del Usuario, dedicado a la instalación (en inglés) y que nos remite con frecuencia al Manual de Instalación: http://doc.openerp.com/book/1/1_1_Inst_Config/index.html
• El fichero INSTALL incluido en la carpeta "doc" de la descarga que se autodefine como una guía rápida.
• La documentación incluida en el código fuente.

Documentación en la web

Al comenzar este artículo, la documentación encontrada en la web también estaba más orientada a Ubuntu:

Versiones de Open ERP 5

Los editores de Open ERP publican una nueva versión cada mes:

• 5.0.11: 2010·JUN·08, http://stephane-wirtel-at-tiny.blogspot.com/2010/06/openerp-5011.html
• 5.0.10: 2010·MAY·05, http://stephane-wirtel-at-tiny.blogspot.com/2010/05/openerp-5010.html
• 5.0.9: 2010·ABR·06, http://stephane-wirtel-at-tiny.blogspot.com/2010/04/openerp-509.html
• 5.0.8: 2010·ABR·06, http://stephane-wirtel-at-tiny.blogspot.com/2010/04/openerp-508.html
• 5.0.7: 2010·MAR·01, http://stephane-wirtel-at-tiny.blogspot.com/2010/03/openerp-507.html
• 5.0.6: 2010·FEB
• ...
• 5.0.0 Alpha 2008·NOV

Por considerarse una aplicación de misión crítica, por el número de versión y por transcurrir sólo un mes entre publicaciones sucesivas, podríamos esperar que cada nueva versión no presentara muchas diferencias respecto a la anterior, que tan sólo solucionara problemas conocidos, los llamados bichos (bugs) y sus correcciones (bugfixes) de forma que cada nueva versión fuera algo así como un bugfix de la anterior. Pero el proyecto Open ERP es mucho más dinámico, en sintonía con Canonical y su Ubuntu.

De modo que Open ERP desde la versión 5.0.7 en adelante ya es compatible con el reciente Python 2.6, mientras que la 5.0.6 y anteriores no lo eran. Justo en la 5.0.7 deja de requerir los paquetes xml (PyXML), libxml2-python y libxslt-python, aunque xml permanece en la lista del instalador, quizás porque el instalador sí lo requiere (ver tabla del apéndice 3); y se introduce una nueva dependencia: lxml, un enlace alternativo a libxml2 y libxslt que reemplaza a los libxml2-python y libxslt-python usados hasta la 5.0.6. Así que la versión 5.0.7 representa un cambio y, como comentan, también alguna regresión que seguramente ya habrá sido corregida en la actual 5.0.11. Al mes siguiente de la 5.0.7 tocaba la versión 5.0.8 la cual no me consta que exista. Algo no muy positivo debió ocurrir al publicar esta versión porque fue "vista y no vista" como indica la fecha de publicación. Versiones más antiguas requerían TurboGears que a su vez depende de CherryPy2. Ahora, openerp-web depende directamente de CherryPy3.

Una errata que presenta el Manual respecto a psycopg: en Ubuntu se indica requerirse sólo la versión 2 pero en Fedora se indican como dependencia tanto la versión 1 como la 2: psycopg y psycopg2. Sin embargo en el documento INSTALL sólo se expresa psycopg2, que es lo correcto en cualquier caso.

Distribuciones Linux y arquitecturas x86 y AMD64

Las diferencias entre las distintas distribuciones Linux son suficientes para que algo que funciona tan suave como la seda en una de ellas, no lo haga igual de bien en otra. Ejemplos de diferencias notables son las "LSB initscript functions" (ver /lib/lsb/ y http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic_lines.txt) y el "empaquetado" de las piezas de software, rpm en unas y deb en otras, así como los administradores de paquetes, es decir, las aplicaciones de instalación/actualización de software: yum y su hermana gráfica yumex, yast, up2date, apt. Tomando dos distribuciones casi idénticas como RHEL y CentOS (CentOS está basado en RHEL), encontramos que CentOS incluye yum y RHEL no. Hay tantas distribuciones que una "Guía de Instalación de Open ERP en Linux" sería algo inmenso. Lo significativo es que el código fuente del software es el mismo, las diferencias comienzan al compilarlo (como si de arquitecturas distintas se tratara) y aumentan al distribuirlo; de modo que a la hora de instalar será mejor asegurarnos de coger el paquete adecuado, o compilarlo correctamente para nuestro sistema o, con suerte, simplemente comprobar que no le afecta especialmente el entorno. Las LSB initscripts functions son usadas en el script de inicio del demonio (servicio) openerp-web pero la implementación en CentOS difiere bastante de Ubuntu.

Por otra parte, la instalación de Open ERP en CentOS 64 no difiere mucho de la misma en CentOS 32, aún cuando las arquitecturas x86 y AMD64 son completamente distintas, basta sustituir los sufijos "x86_64" de los paquetes Linux por "i386". Pero un sistema de 32 bits no puede direccionar más de 4GB de memoria principal (2 elevado a 32). Esta guía está orientada a CentOS 5.5 64 bits, y sirve igual para versiones anteriores como las 5.2, 5.3 y 5.4 porque al actualizarlas convergen. Seguramente pueda extrapolarse a RHEL y Scientific Linux así como a otros sistemas basados en Red Hat como Fedora, tanto a 32 como a 64 bits, con suerte incluso a SLES y openSUSE, del mismo modo que una guía para Ubuntu quizás pueda extrapolarse a otros sistemas basados en Debian.

Métodos de instalación de Open ERP 5

De los distintos cuatro métodos de instalación de Open ERP indicados en el Manual del Usuario, esta guía trata del que aparece en último lugar, el cuarto:

Comparación de los diferentes métodos de instalación en Windows o Linux

Método	Tiempo	Complejidad	Notas
Instalador Todo-en-uno para Windows	Unos pocos minutos	Fácil	Muy útil para una evaluación rápida porque instala todos los componentes pre-configurados en un ordenador (usando el cliente GTK).
Instalación independiente en Windows	Media hora	Medio	Permite instalar los componentes en diferentes ordenadores. Puede ser usado en producción.
Open ERP como paquetes Linux de Ubuntu	Unos pocos minutos	Fácil	Fácil y rápido pero los paquetes Ubuntu no están siempre actualizados.
A partir del código fuente, para todos los sistemas Linux	Más de media hora	Dificultad media a ligeramente difícil	Este es el método recomendado para entornos de producción porque es fácil mantenerlo actualizado.

Guía rápida

No soy partidario de las guías rápidas tipo "haga ésto y esto otro", es como decir "meta vd. la mano que a mí me da risa", pero de alguna forma hay que resumir o sintetizar el proceso de instalación en un sencillo paso-a-paso que nos sirva de referencia. En un primer momento situé este resumen al final, a modo de conclusión pero después lo modifiqué un poco para que sirviera de comienzo, quitando parte del contenido y dejando el resto a modo de apéndice.

La instalación de OpenERP consiste en comprobar una serie de componentes que se relacionan a continuación, algunos deberán ser instalados y otros tendrán que ser actualizados, pero es posible encontrar conflictos. Es importante tener en cuenta que los componentes relacionados son los requeridos tanto por la versión 5.0.6 como por la versión 5.0.11 que es la más reciente al momento de escribir, así que se relacionan más paquetes de los necesarios y se indica la versión de OpenERP que lo requiere.

OpenERP y OpenERP-Web son aplicaciones Python de modo que podemos considerarlas como paquetes Python. Cada paquete Python se denomina un EGG, en referencia a las huevos de la serpiente, un simpático nombre para denominar tanto aplicaciones completas como lo que llamamos bibliotecas, librerías, paquetes, módulos o extensiones de Python. Remotamente, un EGG es a Python lo que un Bean es a Java, mientras que PEAR es a PhP una librería cuyo objetivo es el uso compartido. Algunos paquetes Python están contemplados también como paquetes Linux para facilitar la instalación, administración de las dependencias de otros paquetes, actualización y desinstalación.

Si el paquete Python que queremos instalar no existe como paquete Linux entre los repositorios que estamos usando, puede que exista en repositorios adicionales como CentOS Extras y otros no oficiales como Karan, RPMForge, EPEL u otro (http://wiki.centos.org/AdditionalResources/Repositories), pero mejor que recurrir a repositorios no oficiales es usar setuptools, distutils o la instalación manual. Usar setuptools es una buena opción pero no servirá en todos los casos, de modo que para instalar algún paquete deberemos descargarlo e instalarlo manualmente. Si instalamos repositorios adicionales es importante proteger los repositorios base mediante uno cualquiera de los 3 métodos disponibles: ProtectBase, Priorities y Exclude; y también es recomendable activarlo sólo para instalar dicho paquete y desactivarlo después.

Esta guía le permitirá instalar OpenERP y OpenERP-Web usando solamente repositorios oficiales.

Open ERP Server

1. CentOS 5
   • El contenido de este artículo comienza probando una instalación base (con el repositorio Extras activado y CentosPlus desactivado) de las versión 5.5 de CentOS 64 bits seleccionando los conjuntos de paquetes gnome y server. Aplicando actualizaciones a ésta y anteriores versiones como 5.2, 5.3 y 5.4, las actualizaciones terminaron por igualar los sistemas entre sí. Las pruebas se realizaron tanto en ordenadores de escritorio como servidores HP y con diversos procesadores AMD e Intel, con 8, 4 y 2 GB de memoria principal de los tres tipos, Registered-ECC (Buffered), non-Buffered-ECC y no-ECC. Con sólo 2 GB los resultados no fueron aceptables.
2. RDBMS PostgreSQL 8.2 ó superior (http://www.postgresql.org)
   • CentOS 5 64 incluye la versión 8.1 (8.1.11 y después de actualizar e importar la clave wget, la 8.1.18) que no es suficiente para OpenERP así que deberemos instalar una versión superior por nosotros mismos. PostgreSQL no se instala por defecto pero sí "postgresql-libs-8.1 ... x86_64". Las últimas versiones estables a 18-MAY-2010 son 8.4.4, 8.3.11, 8.2.17, 8.1.21, 8.0.25 y 7.4.29 disponibles para Fedora, RHEL y CentOS en el repositorio de Devrim Gündüz http://yum.pgrpms.org desde 17-MAY-2010. PostgreSQL 7.4 y 8.0 dejarán de estar soportados en julio de 2010 (End of LifeCycle). Entre las versiones superiores encontramos las beta de 9.0. El repositorio recomendado de PostgreSQL para CentOS (The PostgreSQL yum repository, pgdg83, https://public.commandprompt.com/projects/pgcore/wiki) está indicado en http://www.postgresql.org/download/linux donde vemos que aún dice que el repositorio es mantenido por Devrim Gündüz en Command Prompt cuando en realidad, ahora Devrim Gündüz se ha "movido" de Command Prompt comenzando un nuevo repositorio yum: http://yum.pgrpms.org/ (el movimiento se puede apreciar de http://yum.pgsqlrpms.org/howtoyum.php a http://yum.pgrpms.org/howtoyum.php). Como somos seguidores de Devrim instalamos su nuevo repositorio, antes hay que excluir los repositorios de CentOS (exclude postgresql*) e importar la clave pública o instalar sin ella. Lo siguiente es aplicar actualizaciones y además de actualizarse postgresql-libs vemos que se instala compat-postgresql-libs-4-1_x86_64. Si elegimos 8.3 tenemos dos opciones, con soporte ID (Integer Datetimes) para fechas/horas como números enteros o sin él y en este caso será algo más difícil actualizar después a la versión 8.4, aunque Open ERP funcionará bien. Elegimos 8.4 (postgresql-server que depende de postgresql).
   • No es necesario instalar "postgresql-pipython-8.3.10-2PGDG.rhel5.x86_64" o el que corresponda a la versión de PostgreSQL instalada porque OpenERP probablemente usará psycopg2.
   • Una vez instalado PostgreSQL, antes de iniciar el servicio hay que iniciar el directorio de datos "/var/lib/pgsql/data" que en un principio estará vacío (service postgresql initdb). Una vez iniciado el directorio es el momento de iniciar el servicio y crear un usuario de PostgreSQL para OpenERP. El archivo pg_hba.conf en "/var/lib/pgsql/data/" de la configuración de seguridad de PostgreSQL (/var/lib/pgsql/data/pg_hba.conf y pg_ident.conf) limita de forma predeterminada que sólo se permitan conexiones con el servidor de BD desde la propia máquina (local y host 127.0.0.1) y mediante cuentas que existan tanto en el sistema como en el servidor BD (ident sameuser) o relacionadas mediante pg_ident.conf. Desde el punto de vista de la seguridad es mejor que los servidores openerp-server y openerp-web se ejecuten mediante una cuenta limitada y no con una cuenta privilegiada del sistema como root, así que en producción conviene crear un usuario del sistema exclusivamente para la ejecución del servidor OpenERP y que sea este usuario quien acceda a la BD con una cuenta en Postgres que no será de superusuario postgres mientras no necesitemos restaurar una base de datos, todo esto sin relajar la seguridad de postgres en pg_hba.conf, es decir, sin cambiar "ident sameuser" por "trust". Este es el punto más delicado por la seguridad y comprende una serie de inter-relaciones: script de inicio del demonio si ejecutamos OpenERP como servicio, fichero de configuración de inicio del servidor OpenERP (tanto si ejecutamos openerp-server como demonio o como aplicación en un terminal), fichero de configuración de accesos de postgres y cuenta de usuario en el servidor BD.
   • Hay que tener en cuenta que al iniciar el servidor OpenERP, éste no comprueba la conexión con el servidor de BD, así que no nos indicará la imposibilidad de acceso, y después de instalar el cliente web y conectar mediante el navegador, éste nos dirá que "no se pudo conectar con el servidor" y fácilmente podríamos interpretar que "el cliente web no pudo conectar con el servidor OpenERP" cuando lo que está ocurriendo es que "el servidor OpenERP no pudo conectar con el servidor de BD".
   • Recapitulando, si a la hora de probar lo hacemos ejecutando el servidor OpenERP en un terminal, deberá existir una cuenta en el servidor BD para el usuario que ejecutó el servidor OpenERP (o relajar el fichero de acceso de Postgres), y se establecerá dicha cuenta en el parámetro db_user del fichero de configuración de inicio de OpenERP. En caso de ejecutar el servidor OpenERP como demonio, la cuenta dependerá del script de inicio del servicio, si el script permite indicar la cuenta estaremos en un caso similar al anterior y si no, deberemos crear una cuenta para root en el servidor postgres. Crear una cuenta para root en el servidor BD no supone una relajación de la seguridad ya que root puede crearse su cuenta, el punto débil es que el servicio se ejecute con una cuenta privilegiada.
   • Para crear el usuario en el servidor BD iniciamos una sesión root: 1) Usamos psql para crear la cuenta iniciando sesión en el servidor BD con el usario postgres con "su - postgres -c psql" (el guión suelto equivale a -l) y ejecutamos "create user 'nombredeusuarioparaopenerp' with encrypted password 'contraseñafuerte' createdb;" (con el único privilegio de crear bases de datos). La diferencia entre create user y create role es que ceate user es ahora un alias de create role que por defecto otorga privilegio de login mientras que create role no; si usamos create role podemos añadir login después de createdb; el privilegio login lo necesitaremos sólo si en adelante queremos usar esta cuenta al utilizar psql o PgAdminIII.
3. Python 2.4 ó superior (http://www.python.org)
   • CentOS 5 64 incluye Python 2.4 así como numerosos paquetes relacionados. OpenERP funciona bien con la versión 2.4 de Python que encontramos ya instalada: el paquete Linux "python-2.4.3-27.el5.x86_64". Para poder usar Python 2.6 se necesita Open ERP 5.0.7 o más reciente.
4. setuptools
   • Descripción: setuptools es un paquete python, una herramienta para instalar fácilmente paquetes Python. Es requerido por pydot que a su vez es requerido por el instalador de OpenERP (ver el Manual o la definición de "check_modules" dentro del archivo de instalación "setup.py" para comprobar que se requiere "pydot" porque el archivo INSTALL no lo menciona).
   • Instalamos el paquete Linux "python-setuptools-0.6c5-2.el5.noarch" (El sufijo noarch "no architecture" significa que es independiente de la arquitectura y por tanto no existen versiones específicas para 32 ó 64 bits, "i386" ó "x86_64" respectivamente, ya que es válido para ambas). Una vez instalado podemos hacer "easy_install --help" para ver las opciones. Una vez instalado podemos usarlo para actualizarlo a sí mismo "easy_install -U setuptools".
5. psycopg2 (PostgreSQL module)
   • Descripción: Un adaptador de la base de datos PostgreSQL para Python (como pygresql y popy). Escrito desde cero con el objetivo de ser muy pequeño, rápido y estable. Las principales ventajas de psycopg son que soporta completamente Python DBAPI-2.0 y que es thread safe a nivel 2. Ésta es la versión 2, una re-escritura total del código original para proveer un nuevo estilo de clases para los objetos de conexión y cursor y otras dulzuras. Como el original, psycopg2 fue escrito con el objetivo de ser muy pequeño, rápido y estable.
   • CentOS 5 64 incluye las versiones 2.0.7 y 2.0.12 para 64 bits y en el repositorio de PostgreSQL están las versiones 2.0.13 y 2.014 para 64 bits. Instalamos la 14, el paquete Linux "python-psycopg2-2.0.14-1.rhel5.x86_64".
6. pychart
   • Descripción: Usado por OpenERP para generar gráficos de tarta, barras y líneas en diversos formatos como png.
   • CentOS no lo incluye y tampoco easy_install, así que deberemos descargarlo desde "http://home.gna.org/pychart" e instalarlo manualmente, situándonos en el directorio descargado donde se encuentra el instalador y ejecutándolo: "python setup.py install". Sin problema.
7. pyparsing
   • Descripción: Requerido por pydot y usado por OpenERP para renderizar gráficos de flujo (procesos), se trata de un módulo que puede ser usado para configurar, directa y fácilmente, definiciones de sintaxis para cualquier número de aplicaciones de análisis de texto.
   • RPMForge incluye la versión 1.4 ("python-parsing-1.4.11-1.el5.rf.noarch") pero se necesita la 1.5 o superior, que instalaremos fácilmente gracias a setuptools: "easy_install -Z pyparsing". Si tenemos problemas con wikispaces (Download error: name or service not known) podemos indicar el sitio de descarga: "easy_install http://cheeseshop.python.org/packages/source/p/pyparsing/pyparsing-1.5.0.tar.gz".
8. Graphviz (Graph visualization) (http://www.graphviz.org/)
   • Descripción: Usado por OpenERP para renderizar los gráficos de procesos (diagramas de flujo). Se trata de una colección de herramientas y paquetes tcl para la manipulación y composición (disposición) de gráficos entendidos como nodos y aristas y no algo como gráficos de barras (para los que OpenERP usa pychart). Desde el cliente web no se aprecia diferencia en los diagramas de flujo con graphviz instalado y sin él. En el Manual de Open ERP tan sólo se relaciona para Fedora, lo cual no es muy fiable; y también se relaciona en el fichero INSTALL que tampoco es fiable.
   • Graphviz: http://www.research.att.com/sw/tools/graphviz
     Es un modo de representar información estructural como diagramas de gráficos y redes abstractos. El dibujo automático de gráficos tiene muchas e importantes aplicaciones en ingeniería de software, diseño de bases de datos y web, redes, así como en interfaces visuales en muchos otros ámbitos. Graphviz es open source. Tiene diversos programas principales de composición gráfica.
   • CentOS no lo incluye ni tampoco setuptools. Podemos instalar Graphviz usando el repositorio de graphviz con la ayuda del sitio web oficial: descargar graphviz-rhel.repo y ubicarlo en /etc/yum.repos.d que nos facilitará un buen número de versiones hasta 2.26.3-1.el5.x86_64 (al momento de escribir) que depende de freeglut-2.4.0-7.1.el5, gtkglext-libs-1.2.0-6.el5 y gts-0.7.6-11.el5 y otros paquetes relacionados como Webdot. Sin embargo volvemos a necesitar libgvplugin_gd.so.6 para poder cargar graphviz, así que junto a graphviz instalamos también "graphviz-gd" (un plugin de graphviz para renderizadores basados en gd). Al instalar Graphviz se instala también Webdot en el sevidor web Apache de CentOS, un programa cgi-bin que produce gráficos en páginas web donde podemos hacer clic, así como un subdirectorio webdot entre los documentos.
   • En el visor de procesos de OpenERP puede apreciarse que no sea posible ver las descripciones emergentes de las transiciones al situar el puntero del ratón (hover) sobre las flechas de las transiciones, pero instalar graphviz no lo soluciona. En cuanto al error UnicodeDecodeError que puede producirse al hacer doble clic en una transición y al comportamiento general del visor de procesos en IE, se tratan en "OpenERP, Varios".
9. pydot
   • Pydot (http://dkbza.org/pydot.html, http://code.google.com/p/pydot/) es una interfaz Python al lenguaje DOT de Graphviz. Actualmente parece proveer una interfaz completa para crear, manejar y modificar diagramas de flujos en el lenguaje dot de Graphviz. Su sitio web indica que requiere pyparsing para cargar archivos DOT y Graphviz para renderizar los gráficos, pero su archivo "requires.txt" indica que requiere pyparsing y setuptools.
   • CentOS no lo incluye pero podemos instalarlo fácilmente mediante setuptools, "easy_install -Z pydot". Como depende de pyparsing es mejor haber instalado pyparsing previamente y así evitar "Couldn't import dot_parser, loading of dot files will not be possible".
10. Python Imaging Library (PIL)
    • Descripción: Usado por OpenERP, o mejor dicho, por reportlab, para manejar imágenes en formatos distintos a JPG como GIF o PNG a la hora de generar informes, esta librería añade capacidades de proceso de imágenes al intérprete de Python, ofreciendo soporte de un extenso número de formatos, una eficiente representación interna y potentes capacidades de proceso de imágenes.
    • Requerido por reportlab. Instalamos el paquete Linux incluido en CentOS 5 "python-imaging-1.1.5-5.el5.x86_64" que depende de tix y tkinter.
11. reportlab http://www.reportlab.com/
    • Descripción: Biblioteca Python para generar archivos PDF.
    • CentOS no lo incluye. Reportlab requiere Freetype 2, PIL y la librería gzip que es mejor instalar antes. Para instalarlo, ya sea manualmente o mediante setuptools se necesitan los paquetes de desarrollo Python python-devel 64 y 32 y, para soporte de fuentes True Type debemos tener instalada previamente "freetype-devel". El repositorio RPMForge incluye la versión 1.2 "python-reportlab-1.20-1.el5.rf.noarch" que nos daría el error "Unicode() argument 2 must be string not none" al generar un PDF desde OpenERP porque OpenERP requiere la versión 2.4 (la más reciente al momento de escribir). Sus prestaciones pueden acelerarse, opcionalmente, compilando código extra escrito en C para lo que tendremos que instalar primero gcc que también es requerido por el acelerador de simplejson (ejecutar desde compilación en C en lugar de Plain Python) y que necesitaremos para poder instalar lxml, de modo saldremos ganando si desde este punto instalamos gcc. Para instalar reportlab la mejor opción es descargar reportlab del sitio oficial www.reportlab.com y leer las instrucciones de las diversas opciones de instalación incluyendo setuptools.
12. mx by egenix (mxDateTime, etc.)
    • Las extensiones mx para Python (http://pypi.python.org/pypi/egenix-mx-base/3.1.2) son una colección de herramientas software que mejoran la usabilidad de Python en muchas áreas.
    • CentOS incluye "mx-2.0.6-2.2.2.x86_64" que, aunque no se necesita para la instalación de OpenERP, será requerido a la hora de ejecutarlo.
13. pytz
    • Descripción: Definiciones de husos horarios (TimeZones) del mundo para Python. pytz trae la base de datos de "tz" de Olson a Python. Esta biblioteca permite cálculos de husos horarios precisos e independientes de la plataforma usando Python 2.3 o superior. También resuelve el problema de horas ambiguas al final del período en que ha cambiado la hora para ahorro energético de lo que puede ampliar información en la Python Library Reference (datetime.tzinfo). Casi todos los husos Olson (más de 540) están soportados.
    • El repositorio RPMForge incluye el paquete "python-tz-2006p-1.el5.rf.noarch" pero mejor ejecutamos "easy_install -Z pytz" que nos instalará "pytz-2010h-py2.4.egg". OpenERP está actualizado para soportar pytz incluso más recientes que pytz-2008i donde los husos comunes comenzaron a incluir solamente los nombres de las zonas con un correspondiente archivo de datos en zoneinfo (ver final de setup.py de OpenERP).
14. PyXML (sólo 5.0.6 y anteriores)
    • Ya lo encontraremos instalado PyXML-0.8.4-4.el5_4.2.x86_64"
15. libxml2
    • Descripción de libxml2: Permite manipular ficheros XML. Incluye soporte para leer, modificar y escribir archivos XML y HTML. El soporte DTD permite analizar la gramática y validar incluso DTDs complejos al mismo tiempo que el análisis o después de modificar el documento. La salida puede ser un sencillo flujo SAX o representaciones DOM en memoria. En este caso se pueden usar las implementaciones incluidas de XPath y XPointer para seleccionar subnodos o rangos. Dispone de un mecanismo flexible de Entrada/Salida, con módulos HTTP y FTP existentes y combinados con una librería URI.
    • CentOS 5 64 incluye los paquetes Linux "libxml2-2.6.26-2.1.2.8.x86_64" y "libxml2-2.6.26-2.1.2.8.i386", a 64 y 32 bits respectivamente, que proveen soporte XML y HTML y que seguramente ya encontrará instalados y si no es así los instalamos (como Open ERP es una aplicación a 32 bits, sólo necesita la librería i386, pero si está instalando en el área del sistema debería instalar ambas; si sólo instala la librería a 64, OpenERP dará un error de segmentación en las llamadas a esta librería).
16. libxml2-python enlaces python para libxml2 (sólo 5.0.6 y anteriores)
    • Descripción de libxml2-python: Contiene un módulo que permite a las aplicaciones escritas en Python usar la interfaz suministrada por libxml2 para manipular archivos XML.
    • CentOS 5 64 incluye el paquete "libxml2-python 2.6.26-2.1.2.8.x86_64" (los enlaces python a las librerías anteriores) que encontraremos ya instalado.
17. libxslt (libxslt1)
    • Descripción de libxslt: Es una librería C que permite transformar archivos XML en otros archivos XML, HTML, texto, etc. usando el mecanismo estándar XSLT de transformación de hoja de estilo. Para usarlo se necesita tener instalada la versión 2.6.25 de libxml2 o más reciente. El comando xsltproc es una interfaz de línea de comandos al motor de XSLT.
    • CentOS 5 64 incluye los paquetes "libxslt-1.1.17-2.el5_2.2.x86_64" y "libxslt-1.1.17-2.el5_2.2.i386" a 64 y 32 bits respectivamente, la primera la encontraremos ya instalada.
18. libxslt-python los enlaces python (sólo 5.0.6 y anteriores)
    • Descripción de libxslt-python: Contiene un módulo que permite a las aplicaciones escritas en Python usar la interfaz de la librería libxslt para aplicar transformaciones XSLT. Permite analizar hojas de estilo, usa libxml2-python para cargar y guardar archivos XML y HTML. Es posible acceder directamente a XPath y al contexto de transformación XSLT para extender el lenguaje XSLT con funciones XPath escritas en Python.
    • Encontramos ya instalado el paquete Linux "libxslt-python-1.1.17-2.el5_2.2.x86_64".
19. lxml (lxml module: pythonic libxml2 and libxslt bindings) http://codespeak.net/lxml/ (sólo 5.0.7 y superiores)
    • Descripción: Requerido por OpenERP a partir de la versión 5.0.7 en adelante, se trata de enlaces Python para libxml2 y libxslt similares a ElementTree. Sigue lo más posible la API de ElementTree para proveer una interfaz a libxml2 y libxslt más pitónica que los enlaces predeterminados. En concreto, lxml trata con cadenas literales Unicode de Python en lugar de codificadas UTF-8 y maneja automáticamente la administración de memoria, al contrario que los enlaces predeterminados.
    • Este es uno de los puntos más delicados porque lxml no se incluye en ninguno de los repositorios CentOS y porque tanto elementtree como los enlaces a libxml2 y libxslt ya los encontramos instalados y pueden confundirnos; y en parte también porque deberemos compilarlo pero ésto resultará sencillo. El repositorio RPMForge incluye el paquete "python-lxml-1.3.4-1.el5.rf.x86_64" pero producirá errores de segmentación. Para compilar e instalar simplemente ejecutaremos "easy_install -Z lxml" que encontrará la versión 2.2.6 que es la más reciente y tratará de compilarla para su instalación pero antes debemos tener en cuenta que se necesitarán los paquetes de desarrollo libxml2-devel y libxslt-devel. Si no los instalamos previamente tratará de compilar lxml con los binarios de libxml2 y libxslt, nos llenará el terminal con un montón de líneas de error y terminará con "error: Setup script exited with error: command 'gcc' failed with exit status 1". Pero si tenemos instalados los paquetes devel tan sólo veremos unas pocas líneas: "Building against libxml2/libxslt in /usr/lib64", "Adding lxml to easy_install.pth" e "Installed /usr/lib/python/site-packages/lxml-2.2.6-py2.4-linux-x86_64.egg". Al comienzo vemos que el script trata de encontrar Cython para usarlo en la compilación en lugar de gcc, pero CentOS no incluye Cython.
20. openerp-server
    • En este momento en que estoy escribiendo, no es aconsejable por ahora usar setuptools para instalar OpenERP ya que si ejecutamos "easy_install openerp-server" se instalará la versión 5.0.0-3 y además no quedará del todo bien instalada, mientras que en la zona de descarga de Open ERP está disponible la versión 5.0.10 que podemos instalar situándonos en el directorio donde se encuentra el instalador y ejecutándolo "python setup.py install" ó "python ./setup.py install". Antes podemos ver las opciones de instalación haciendo "python ./setup.py --help-commands", en cualquier caso quedará instaldo en ""/usr/lib/python2.4/site-packages/openerp-server .
21. configurando openerp-server
    • Si los puertos IP predeterminados (8069 y 8070) que va a usar el servidor openerp están libres (normalmente así será y así es en una instalación base), el siguiente paso es ejecutar el servidor openerp en un terminal con la opción -s (save) "openerp-server -s" que creará un fichero oculto en el home del usuario que lo ejecuta ".openerp-serverrc" con las opciones de inicio (configuración de inicio). Terminamos la ejecución con "Ctrl+C" para pasar a editar este fichero de configuración de inicio. Las líneas no se guardarán precisamente ordenadas y podemos compararlas con las opciones de ejecución que vemos en "man openerp-server" porque son casi las mismas. La línea "admin_password" es la contraseña del super-administrador de OpenERP necesaria para, desde la interfaz de usuario (cliente de OpenERP), crear o eliminar una base de datos (esquema o compañía), hacer una copia de respaldo (de seguridad) o restaurar desde la anterior. OpenERP pedirá esta contraseña (sólo la contraseña sin nombre de usuario) y si es correcta conectará con PostgreSQL usando la cuenta indicada en la línea "db_user" de este fichero de configuración que será la del usuario que habíamos creado para éste y otros propósitos, al comienzo de esta guía. La línea "db_password" no será necesaria cambiarla, la dejamos en False (ver PostgreSQL authentication). En este punto ya es posible ejecutar el programa en un terminal invocando "openerp-server" para que corra el script del mismo nombre ubicado en "/usr/bin". Recuerde que al arrancar el servidor openerp, éste no comprueba la conexión con el servidor de BD y por tanto no recibiremos alerta alguna si la cuenta indicada en "db_user" no es válida en el servidor BD. Cuando iniciemos openerp web y nos conectemos mediante un navegador, éste nos indicará que no se pudo conectar con el servidor, pero será un mensaje ambiguo ya que perfectamente podríamos interpretar que openerp-web no pudo conectar con openerp-server cuando lo que ocurre es que este último no pudo conectar con el servidor BD.
22. ejecutando openerp-server
    • Ahora ya sólo queda configurar el servidor para que el programa se ejecute como servicio para no tener que ejecutarlo en un terminal. Básicamente consiste en situar el fichero de configuración en el directorio "/etc/", ubicar en "/etc/init.d/" el script de arranque (que no es el mismo del paso anterior y tampoco se facilita en la descarga), otorgarle permiso de ejecución, añadirlo como servicio "chkconfig --add openerp-server" y establecer los niveles de ejecución en que estará disponible, por ejemplo, para todos, sería "chkconfig openerp-server on" y para el nivel 5 "chkconfig -level 5 openerp-server on" y para los niveles 3 y 5 "chkconfig -level 35 openerp-server on". Usando off podemos hacer que no esté disponible en alguno o todos los niveles de ejecución. También podemos usar la interfaz gráfica: "System, Administration, Server Settings, Services" y entonces "Actions, Add Service" y escribimos "openerp-server", activamos su casilla y hacemos clic en "Guardar".

Open ERP Web

1. CherryPy >= 3.1.2
   • CherryPy3 colisiona con CherryPy2 (usado por TurboGears) así que no podemos instalar ambos en el área del sistema. En el caso de que necesitemos tener CherryPy2 en el sistema, podemos hacer una instalación local de CherryPy3 y las demás librerías en el subdirectorio lib de la carpeta de openerp-web, ubicándonos en el directorio lib y ejecutando "./populate.sh" que instalará todas las dependencias necesarias en el directorio privado lib; no necesitaremos instalar nada más.
   • CherryPy >= 3.1.2 "easy_install -Z cherrypy" instalará la versión 3.1.2 y el script "cherryd" en /usr/bin/
2. pycryptopp >= 0.5.12
   • Puede ser requerido por Beaker que instalaremos a continuación, si usamos alguna función de cifrado. Como requiere la versión 0.6c6 de setuptools que es más reciente que la 0.6c5 que hemos instalado, ejecutamos "easy_install -U setuptools" que actualiza a 0.6c11 y después "easy_install -Z pycryptopp" que falla y entonces instalamos manualmente.
3. Beaker >= 1.5
   • Descripción: Una librería general de caché y sesión web que incluye WSGI middleware para usar en aplicaciones web, construida a partir de MyghtyUtils y extendida con soporte de BD, http://beaker.groovie.org
   • La versión 1.1 o superior es requerida por Mako, que instalaremos a continuación, pero la versión 1.5 es requerida por openerp-web, de modo que "easy_install -Z beaker" instalará la versión 1.5.3 y ningún script, como es lógico.
4. Mako >= 0.2.4
   • Descripción: Una librería de plantillas que toma prestadas las mejores ideas de las plantillas de Django, Cheetah, Myghty y Genshi. Mako es un lenguaje Python incrustado (es decir, Python Server Page).
   • "easy_install -Z mako" instalará la versión 0.3.2 y el script "mako-render" en /usr/bin/
5. Babel >= 0.9.4
   • Útiles de internacionalización, una colección de herramientas para internacionalizar aplicaciones Python http://babel.edgewall.org Edgewall Software
   • "easy_install -Z babel" instalará la versión 0.9.5 y el script "pybabel" en /usr/bin/
6. FormEncode >= 1.2.2
   • HTML form validation, generation and conversion.
   • "easy_install -Z formencode" instalará la versión 1.2.2 y ningún script en /usr/bin/
7. simplejson >= 2.0.9
   • RPMForge incluye la versión 2.0.5 ("python-simplejson-2.0.5-1.el5.rf.x86_64") que no es suficiente, así que "easy_install -Z simplejson" instalará la versión 2.1.1 y ningún script en /usr/bin/ Simplejson ya viene incluido en Python 2.6 y es compatible con 2.5 pero hay que instalarlo por separado, también para la 2.4.
8. pyparsing >= 1.5.0
   • Ya lo hemos instalado.
9. xlwt >= 0.7 (0.7.2)
   • Es una librería para generar archivos xls con formato de hoja de cálculo compatible con MS Excel 97/2000/XP/2003, OpenOffice.org, y Gnumeric con soprte Unicode completo. Sólo requiere Python 2.3 o superior. Se trata de una bifucarción de pyExcelerator. Será requerido por openerp-web y podemos instalarlo con easy_install.
10. openerp-web
    • Al contrario que con openerp-server, setuptools sí que puede ayudarnos perfectamente a instalar la última versión (5.0.10 en el momento de escribir) de openerp-web, así que "easy_install -UZ openerp-web" lo dejará bien instalado en "/usr/lib/python2.4/site-packages/openerp_web-5.0.10-py2.4.egg". Si los instalamos de esta forma, las dependencias que fueron indicadas en el archivo doc/README.txt podemos verlas ahora en el archivo "EGG-INFO/requires.txt":
      

      CherryPy >= 3.1.2
      Mako >= 0.2.4
      Babel >= 0.9.4
      FormEncode >= 1.2.2
      simplejson >= 2.0.9
      pyparsing >= 1.5.0
      

    • También es posible probar OpenERP web en Linux sin necesidad de instalarlo, usando el script "populate.sh" incluido en la subcarpeta lib de la descarga, que ubica todos los paquetes Python necesarios en esa misma subcarpeta. Después podemos ejecutarlo desde ahí mismo.
11. configurando openerp-web
    • El siguiente paso es editar el fichero de configuración de inicio "openerp-web.cfg" que encontramos en el directorio "config". En este punto ya es posible ejecutar el programa en un terminal invocando "openerp-web" para que corra el script del mismo nombre en "/usr/bin".
12. ejecutando openerp-web como demonio
    • Ahora ya sólo queda configurar el servidor para que el programa se ejecute como servicio para no tener que ejecutarlo en un terminal. Básicamente consiste en situar el fichero de configuración en el directorio "/etc/", copiar a "/etc/init.d/" el script de arranque (que no es el mismo del paso anterior sino el que encontramos en el directorio "scripts"), hacerle unos mínimos cambios porque LSB es distinto en CentOS que en Ubuntu y añadirlo como servicio.

Problemas

Conocer lo que hace cada extensión de Python puede ayudarnos a aislar problemas, por ejemplo, si encontramos un problema al generar un documento PDF es muy probable que la causa esté en reportlab. Este fue el motivo de incluir una descripción de cada extensión. No he comprobado algunas extensiones Python mencionadas en otras guías, como python-vobject, python-matplotlib (depende de python-dateutil), python-matplotlib-data y python-hippocanvas.

Si ejecutamos openerp-server en un Terminal, he encontrado problemas si el idioma del usuario del sistema es distinto del inglés, el típico problema del separador decimal. Esto no tiene nada que ver con el idioma de los usuarios de OpenERP que puede estar perfectamente en español.

Apéndice 1. Instalando paquetes Python: setuptools (también conocido como easy_install)

http://cheeseshop.python.org/pypi/setuptools

Instalación de paquetes Python

Instalar en el área del sistema (/usr/lib/python/site-packages y /usr/lib64/python/site-packages) los paquetes Python necesarios para ejecutar OpenERP puede resultar sencillo usando setuptools, también conocido como easy_install, que es una colección de mejoras a las distutils de Python que permite compilar y distribuir paquetes Python más fácilmente, especialmente aquellos que tienen dependencia de otros paquetes, su funcionalidad consiste en descargar, compilar, instalar, actualizar y ¿desinstalar? paquetes Python. He escrito desinstalar entre interrogantes porque la descripción del paquete indica que tiene esta capacidad pero no existe un comando u opción para este fin. Igual que ocurre con los módulos de Open ERP, la operación de desinstalación será más compleja, aunque no tanto como en OpenERP, lo que debemos tener presente a la hora de instalar.

CentOS 5 incluye "python-setuptools-0.6c5-2.el.noarch".

Por defecto setuptools se instala junto con los paquetes Python en "/usr/lib/python/site-packages/setuptools" y podemos usarlo directamente desde un terminal porque en "/usr/bin/" se instala el script correspondiente. Como no tiene una entrada de manual de documentación no obtendremos resultado de "man easy_install" pero podemos probar "easy_install --help" donde vemos las posibles opciones entre las que no vemos nada acerca de desinstalar.

Al ejecutar easy_install, lo primero que hace es buscar el paquete en la web (searching, reading), cuando encuentra la mejor versión (best match) lo descarga (downloading) y lo instala (running setup.py). El script setup.py del paquete puede haber sido implementado específicamente para setuptools o adaptado para que sea compatible como es el caso de reportlab.

A continuación hace lo mismo con sus dependencias (Processing dependencies) que registra en el archivo "requires.txt" bajo el directorio "EGG-INFO" del paquete, y registra los paquetes instalados y su ubicación en el archivo "easy_install.pth" que encontraremos en "/usr/lib/python2.4/site-packages" y que tiene el aspecto siguiente:

import sys; sys.__plen = len(sys.path)
./pyparsing-1.5.0-py2.4.egg
./CherryPy-3.1.2-py2.4.egg
./Mako-0.2.5-py2.4.egg
./Beaker-1.5-py2.4.egg
./Babel-0.9.4-py2.4.egg
./FormEncode-1.2.2-py2.4.egg
./reportlab-2.4-py2.4-linux-x86_64.egg
./openerp_web-5.0.9-py2.4.egg
./pydot-1.0.2-py2.4.egg
./simplejson-2.1.1-py2.4-linux-x86_64.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; 
   p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)

Si la búsqueda en la web es infructuosa, el proceso se interrumpirá en el momento de la descarga:

[Civicom@www ~]# easy_install pyparsing
Searching for pyparsing
Reading http://cheeseshop.python.org/pypi/pyparsing/
Reading http://pyparsing.wikispaces.com/
error: Download error: (-2, 'Name or service not known')

En este caso podemos indicar explícitamente la dirección URI:

[Civicom@www ~]# easy_install http://cheeseshop.python.org/packages/
   source/p/pyparsing/pyparsing-1.5.0.tar.gz
Downloading http://cheeseshop.python.org/packages/
   source/p/pyparsing/pyparsing-1.5.0.tar.gz
Processing pyparsing-1.5.0.tar.gz
Running pyparsing-1.5.0/setup.py -q bdist_egg --dist-dir 
   /tmp/easy_install-SHSQ5X/pyparsing-1.5.0/egg-dist-tmp-5O8Vnm
zip_safe flag not set; analyzing archive contents...
pyparsing: module MAY be using inspect.stack
pyparsing: top-level module may be 'python -m' script
Adding pyparsing 1.5.0 to easy-install.pth file
Installed /usr/lib/python2.4/site-packages/pyparsing-1.5.0-py2.4.egg
Processing dependencies for pyparsing==1.5.0

Para instalar un paquete ejecutamos "easy_install paquete" pero seguramente querremos controlar si se instalará como zip o como directorio ya que cada paquete tiene su formato predeterminado, p.e., simplejson y pydot se instalan en zip si no especificamos nada. Podemos forzar el formato mediante las opciones: la opción -z (--zip-ok) instala el paquete en formato zip, mientras que la opción -Z (--always-unzip) lo instala descomprimido en su propia carpeta.

Actualización de paquetes

Para actualizar un paquete que hemos instalado previamente con easy_install usamos la opción -U (--upgrade) que comprobará la versión instalada y la versión disponible más reciente, si coinciden, setuptools informa que la versión instalada es la más reciente y no hace nada más. Hay que tener cierto cuidado si previamente habíamos instalado el paquete que vamos a actualizar usando otro método (p.e. manualmente) porque será ignorada por easy_install aunque sea más reciente al no haberse registrado en el archivo de paquetes instalados (la versión más reciente disponible para setuptools puede no ser la última, que puede estar disponible en el sitio oficial de descarga, por ejemplo, en el momento de escribir, la versión de openerp-server disponible para descarga es la 5.0.10 mientras que para easy_install es la 5.0.0-3), es decir, easy_install sólo tiene en cuenta las versiones de los paquetes que han sido instalados previamente por él mismo, las que están registradas en easy_install.pth; una actualización tiene el aspecto siguiente:

[Civicom@www ~]# easy_install -UZ simplejson
Searching for simplejson
Reading http://cheeseshop.python.org/pypi/simplejson/
Reading http://undefined.org/python/#simplejson
Reading http://cheeseshop.python.org/pypi/simplejson/2.1.1
Best match: simplejson 2.1.1
Downloading http://pypi.python.org/packages/source/s/simplejson/
   simplejson-2.1.1.tar.gz#md5=0bbe3a2e5e4cac040013733aca159d89
Processing simplejson-2.1.1.tar.gz
Running simplejson-2.1.1/setup.py -q bdist_egg --dist-dir 
   /tmp/easy_install-WeImCz/simplejson-2.1.1/egg-dist-tmp-GuhBjm
Removing simplejson 2.0.9 from easy-install.pth file
Adding simplejson 2.1.1 to easy-install.pth file

Installed /usr/lib/python2.4/site-packages/simplejson-2.1.1-py2.4-linux-x86_64.egg
Processing dependencies for simplejson

Como resultado de la actualización tenemos una nueva carpeta adicional ya que la carpeta de la versión anterior no es borrada, porque easy_install puede hacer que las aplicaciones requieran una versión determinada y por tanto es posible tener instalada más de una versión. Si no la necesitamos para otro programa podemos eliminarla manualmente.

Desinstalar paquetes instalados con setuptools

En principio, para desinstalar un paquete instalado con setptools basta con eliminar su carpeta y la referencia a la misma en el archivo "easy_install.pth", por ejemplo, en el caso de que vayamos a volver a instalarlo (por ejemplo, si lo instalamos sin gcc y queremos volver a instalarlo con gcc) y también en el caso de que no sea necesario como dependencia de ningún otro paquete. Si el paquete se necesita como dependencia de algún otro y hay instalada otra versión del mismo paquete que sea válida basta comprobar las referencias en el archivo .pth". En el caso de que queramos eliminarlo de forma permanente y sea necesario como dependencia de algún otro paquete, entonces esta dependencia estará registrada en el archivo "require.txt" de ese otro paquete y al actualizarlo se volverán a procesar las dependencias. Podemos eliminar estas dependendencias manualmente, usar la opción -m o actualizar usando la opción -N (--no-deps) que instala si procesar dependencias.

Apéndice 2. Instalación manual vs. setuptools

easy_install

A la hora de instalar un paquete python podemos elegir usar setuptools que es una aplicación que facilita la instalación, actualización y administración de dependencias de paquetes python. Por ejemplo, tomemos el paquete pydot que depende de pyparsing y setuptools, podemos instalarlo ejecutando "easy_install pydot" y usando la opción -Z "easy_install -Z pydot" para asegurarnos que se instale descomprimido en una carpeta y no en formato zip. La instalación se realiza en el área del sistema, es decir, en el directorio "site-packages" (/usr/lib/python/site-packages/):

[Civicom@www ~]# easy_install -Z pydot
Searching for pydot
Reading http://cheeseshop.python.org/pypi/pydot/
Reading http://code.google.com/p/pydot/
Reading http://cheeseshop.python.org/pypi/pydot/1.0.2
Best match: pydot 1.0.2
Downloading http://pydot.googlecode.com/files/pydot-1.0.2.zip
Processing pydot-1.0.2.zip
Running pydot-1.0.2/setup.py -q bdist_egg --dist-dir 
   /tmp/easy_install-hbpcsj/pydot-1.0.2/egg-dist-tmp-e9iej8
zip_safe flag not set; analyzing archive contents...
Adding pydot 1.0.2 to easy-install.pth file
Installed /usr/lib/python2.4/site-packages/pydot-1.0.2-py2.4.egg
Processing dependencies for pydot

instalación manual

O usar el instalador del paquete. Por ejemplo, podemos instalar pydot usando su instalador: descargamos el paquete, nos situamos en el directorio del paquete descargado donde se encuentra el instalador y lo ejecutamos, "python setup.py install".

[Civicom@www pydot-1.0.2]# python setup.py install
running install
running bdist_egg
running egg_info
writing requirements to pydot.egg-info/requires.txt
writing pydot.egg-info/PKG-INFO
writing top-level names to pydot.egg-info/top_level.txt
writing dependency_links to pydot.egg-info/dependency_links.txt
reading manifest file 'pydot.egg-info/SOURCES.txt'
writing manifest file 'pydot.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
copying build/lib/pydot.py -> build/bdist.linux-x86_64/egg
copying build/lib/dot_parser.py -> build/bdist.linux-x86_64/egg
byte-compiling build/bdist.linux-x86_64/egg/pydot.py to pydot.pyc
byte-compiling build/bdist.linux-x86_64/egg/dot_parser.py to dot_parser.pyc
installing package data to build/bdist.linux-x86_64/egg
running install_data
copying ChangeLog -> build/bdist.linux-x86_64/egg/.
copying LICENSE -> build/bdist.linux-x86_64/egg/.
copying README -> build/bdist.linux-x86_64/egg/.
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying pydot.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying pydot.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying pydot.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying pydot.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying pydot.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating dist
creating 'dist/pydot-1.0.2-py2.4.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing pydot-1.0.2-py2.4.egg
Copying pydot-1.0.2-py2.4.egg to /usr/lib/python2.4/site-packages
Adding pydot 1.0.2 to easy-install.pth file
Installed /usr/lib/python2.4/site-packages/pydot-1.0.2-py2.4.egg
Processing dependencies for pydot==1.0.2
Searching for pyparsing
Reading http://cheeseshop.python.org/pypi/pyparsing/
Reading http://pyparsing.wikispaces.com/
error: Download error: (-2, 'Name or service not known')

Si todo estaba correcto el resultado será parecido, especialmente en el caso de pydot que usa setuptools, pero si no (p.e. si no tenemos instalado setuptools que es requerido por pydot), es posible que la instalación sea infructuosa y nos encontremos con una serie de archivos ubicados incorrectamente:

[Civicom@www pydot-1.0.2]# python setup.py install
/usr/lib64/python2.4/distutils/dist.py:236: UserWarning: 
   Unknown distribution option: 'install requires'
warnings.warn(msg)
running install 
running build
running build_py
creating build
creating build/lib
copying pydot.py -> build/lib
copying dot_parser.py -> build/lib
running install_lib
copying build/lib/pydot.py -> usr/lib/python2.4/site-packages
copying build/lib/dot_parser.py -> /usr/lib/python2.4/site-packages
byte-compiling /usr/lib/python2.4/site-packages/pydot.py to pydot.pyc
byte-compiling /usr/lib/python2.4/site-packages/dot_parser.py to dot_parser.pyc
running install_data
copying Changelog -> /usr/.
copying LICENSE -> /usr/.
copying README -> /usr/.

Así que, si hemos de probar, quizás sea mejor hacerlo primero aceptando la ayuda de easy_install, que realiza las operaciones en /tmp antes de instalar; si falla, antes de terminarse nos mostrará un mensaje y borrará la carpeta que creó en /tmp.

Apéndice 3. Dependencias de Open ERP según INSTALL y el instalador setup.py

Documento INSTALL

Al descargar Open ERP, encontramos en la carpeta doc el fichero INSTALL que se autodefine como una guía rápida de instalación. El archivo relaciona una serie de paquetes que necesitamos tener instalados y las instrucciones para instalarlos en sistemas basados en Debian como Ubuntu (apt-get install -y) y en Fedora (usando yum ó los repositorios "core" ó "extra" del sitio web de Fedora). Este documento no es fiable porque presenta contradicciones no sólo respecto al Manual sino en sí mismo. El Manual indica que desde 5.0.7 ya no son necesarios libxml2 ni libxslt y aquí siguen apareciendo.

Si comparamos las versiones 5.06, 5.07, 5.09 7 5.0.10, la lista que aparece en primer lugar es la misma en los cuatro, pero en el comando apt-get hay una diferencia: en la versión 5.0.9 y 10 ya no aparece "python-xml" entre los paquetes Linux a instalar para Debian, paquete que no debería aparecer en 5.0.7 y que no se indica para Fedora en ninguno de los tres. Este no es necesario desde 5.0.7 así que puede servir de indicador de si una guía de instalación está actualizada o no.

La siguiente tabla resume la primera lista de este fichero INSTALL: en la primera columna tenemos la relación de software, en la segunda los paquetes de la instalación para Ubuntu y en la tercera para Fedora (algunos paquetes Python existen como paquetes Linux).

Software	Ubuntu	Fedora
Python 2.4 ó 2.5
PostgreSQL 8.2 ó superior	postgresql	postgresql-python
Psycopg2, el módulo Python	python-psycopg2	python-psycopg2
libxml2 y los enlaces (empalmes) Python	python-libxml2	libxml2-python
libxslt y los enlaces (empalmes) Python	python-libxslt1	libxslt-python
lxml, el módulo Python	python-lxml	python-lxml
Reportlab pdf generation library for Python		python-reportlab
pytz, el módulo Python	python-tz
Algunas dependencias son requeridas solamente para propósitos específicos:
Para renderizar gráficos de flujos:
graphviz	graphviz	graphviz
pyparsing
Para generar informes usando imágenes en otro formato que .jpg:
Python Imaging Library (PIL)	python-imaging	python-imaging

La diferencia entre las instrucciones para Ubuntu frente a Fedora son que para Ubuntu no se indica "python-reportlab" (que es necesario y que seguramente ya esté instalado, lo que deberemos comprobar) y para Fedora no se indica "python-tz" que es un paquete básico de husos horarios (time zone) que seguramente encontremos ya instalado.

El fichero INSTALL continúa con una referencia a "pyparsing", indicándonos que lo podemos encontrar en http://pyparsing.sourceforge.net/ y termina sugiriendo que ejecutemos OpenERP directamente, desde el directorio donde lo hemos descargado, lo cual es útil como comprobación final de que los paquetes imprescindibles están instalados.

setup.py

Ahora, si miramos el archivo setup.py de instalación vemos que el instalador buscará una serie de módulos (check_modules) y que en caso de no encontrarse informará y terminará. Esta lista de módulos es distinta a las que encontramos en el archivo setup.py de las versiones 5.0.7 y 5.06, así que vamos a hacer una tabla para ver mejor los módulos requeridos por el instalador de Open ERP de cada versión:

Módulo	5.0.9 y 10	5.0.7	5.0.6
psycopg2	Sí	Sí	Sí
xml	No	Sí	Sí
libxml2	No	No	Sí
libxslt	No	No	Sí
lxml	Sí	Sí	No
reportlab	Sí	Sí	Sí
pychart	Sí	Sí	Sí
pydot	Sí	Sí	Sí

Esta tabla indica solamente aquellos paquetes que el instalador comprueba que estén instalados como requisito para ejecutarse, nada más, pero aún así, significa que pychart y pydot de alguna manera hay que contemplarlos también como requeridos por OpenERP.