Entorno de desarrollo para OpacMarc

En esta página describo el entorno que estoy utilizando en mi PC para trabajar en el desarrollo de OpacMarc. Otros desarrolladores o testeadores que deseen colaborar en el proyecto están invitados a reproducir un entorno similar en sus propias máquinas.

Ante todo, aclaremos que realizo la mayor parte del desarrollo bajo Linux (al momento de escribir esto, Ubuntu 8.04), de manera que el entorno aquí descripto está orientado a esa plataforma. Con algunas variantes se puede trasladar esto mismo a Windows.

Software requerido

subversion

sudo apt-get install subversion

La versión 1.4 está bien. (Es la que utiliza Google Code para el repositorio donde está alojado el código de OpacMarc.)

Si usa un proxy para acceder a la Web, deberá configurar apropiadamente el cliente de Subversion.

Para que ciertos tipos de archivos no sean tomados en cuenta por Subversion, podemos (en Linux) editar el archivo ~/.subversion/config y modificar el parámetro de configuración global-ignores. Por ejemplo, en mi instalación de Ubuntu tenía esta línea:

# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

Para que ignore los archivos .pyc (generados por Python) la convertí en:

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.pyc

Es útil también el script wcgrep, que facilita el uso de grep dentro de la copia de trabajo, omitiendo los directorios administrativos .svn.

python

Estoy usando 2.5; puede andar con 2.4 y quizás con 2.3.

apache

agrep

sudo apt-get install agrep

Estructura de carpetas

Uso esta estructura de carpetas:

opacmarc/
|-- binaries/
|-- builds/
|-- local-testdata/
|-- svn/
`-- test-install/

La carpeta opacmarc actualmente la tengo en $HOME/dev, pero cada uno es libre de ubicarla donde prefiera. En caso de modificar su ubicación, habrá que ajustar algunos archivos de configuración que luego mencionaremos.

Veamos qué hay en cada subcarpeta:

binaries - aquí tenemos archivos ejecutables necesarios para la aplicación, agrupados por plataforma. Un archivo tgz con el contenido de esta carpeta se puede descargar desde aquí: opacmarc-binaries.tgz (6 MB, incluye versiones para Linux y para Windows).

binaries/
|-- linux/
| |-- cisis-5.2b-1030/
| |-- cisis-5.2b-1660/
| |-- wxis-5.2b-1030
| `-- wxis-5.2b-1660
`-- windows/
|-- agrep.exe
|-- cisis-5.2b-1030/
|-- cisis-5.2b-1660/
|-- wxis-5.2b-1030.exe
`-- wxis-5.2b-1660.exe

builds (opcional) - Aquí se almacenan los builds de OpacMarc, que son los archivos tgz que un usuario ---no un desarrollador--- bajaría para instalar OpacMarc. Inicialmente la carpeta está vacía; se va poblando a medida que ejecutamos el script build.sh.

local-testdata (opcional) - Si además de la base demo incluida en OpacMarc queremos hacer pruebas con algunas de nuestras propias bases, podemos alojarlas en esta carpeta. mostrar ejemplo.

svn - Aquí está el código bajo control de versiones. Inicialmente hay que hacer un checkout del repositorio.

test-install - Contiene una instalación de prueba de OpacMarc, generada a partir del contenido de las carpetas svn, binaries y (opcionalmente) local-testdata. Cada vez que ejecutamos el script test.sh se recrea la carpeta y todo su contenido. La configuración de Apache apunta a esta carpeta.

test-install/
|-- app/
`-- local-data/

Archivos de configuración

Estoy usando dos archivos con parámetros de configuración relacionados con el trabajo de desarrollo:

test-config.sh: requerido para test.sh, el script que genera la instalación de prueba.

build-config.sh: requerido para build.sh, el script que produce los builds.

Estos archivos son locales, y por lo tanto no están bajo control de versiones. Sí están en el repositorio versiones de muestra de cada uno de ellos: test-config.sh.dummy y build-config.sh.dummy. Luego de hacer el checkout inicial, haga una copia de ambos archivos, quite de sus nombres el sufijo .dummy, y edítelos para ajustar los valores de los parámetros.

Explicar bien qué hay que modificar.

Configuración de Apache

Creamos un archivo vacío, que luego será reemplazado por la configuración del virtual host para OpacMarc, y creamos un link simbólico para habilitar ese “sitio”:

sudo touch /etc/apache2/sites-available/opacmarc-test
sudo ln -s /etc/apache2/sites-available/opacmarc-test /etc/apache2/sites-enabled/

Testeo

cd svn
./test.sh

Este script realiza la “instalación” y luego habilita el acceso a la base demo. Abre una ventana de Firefox donde se muestra la página inicial del OPAC.

Para ejecutar test.sh se requieren privilegios de administrador (sudo).

Explicar mejor lo que hace el script, y la opción de usar otras bases locales.

Build

cd svn
./build.sh

Explicar el upload.

Actualización del código

Para descargar a la copia de trabajo local los cambios que se hayan producido en el repositorio,

cd svn
svn update

(o el equivalente que corresponda si se usa una interfaz gráfica).

Modificaciones al código

Con la estructura que estoy usando, los cambios que se realicen en el código de la aplicación (es decir, cualquier cambio hecho dentro de la carpeta svn) no tendrán efecto inmediato en nuestra instalación de prueba. Para testear el efecto de esos cambios, tendremos que ejecutar test.sh.

Esto puede parecer una molestia, dado que hay que esperar mientras el script se ejecuta, pero no son más que unos pocos segundos (entre 20 y 40 en las máquinas que uso, con una base demo de 100 registros). La molestia me ha parecido aceptable, a cambio de contar en todo momento con una copia de trabajo limpia, no “contaminada” por las carpetas y arcchivos que son creados como producto del proceso de instalación.

Alternativamente, podemos editar los archivos de la carpeta test-install, y entonces sí veremos los efectos en el OPAC en forma inmediata (por supuesto, dependiendo esto de cuáles archivos editemos). Sin embargo, este procedimiento tiene una desventaja: debemos acordarnos de trasladar todos esos cambios a la copia de trabajo que tenemos en svn, y dado que los archivos de test-install no están bajo control de versiones, no siempre será fácil detectar todos los cambios que hemos realizado.

Si añadimos un nuevo archivo dentro de svn, éste no será tenido en cuenta en el testeo a menos que lo “demos de alta” mediante el comando svn add (o el equivalente que corresponda si se usa una interfaz gráfica).