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.

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.

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

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

sudo apt-get install agrep

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.

• 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/

• local-testdata (opcional) - Aquí guardamos una copia persistente de datos locales que queramos usar para el testeo del OPAC. Con “persistente” queremos decir que estos datos sobreviven a la eliminación completa de test-install que resulta de volver a ejecutar test.sh (recordar que los datos locales “normales” viven en test-install/local-data). Por ejemplo, es de esperar que, además de la base demo incluida en OpacMarc, nos interese hacer pruebas con algunas de nuestras propias bases bibliográficas. mostrar ejemplo.

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.

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/

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.

cd svn
./build.sh

Explicar el upload.

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).

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).

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

Este parámetro tiene un efecto global sobre todas las copias de trabajo en mi máquina. Por otra parte, si deseamos ignorar archivos específicos de una determinada copia de trabajo, podemos setear la propiedad svn:ignore para uno o más directorios.

2009-05-19: estos son los valores de svn:ignore en mis copias de trabajo de opacmarc. Esos valores están almacenados en el repositorio (los cambios se transfieren mediante las operaciones de commit y update). Ver si aún tienen sentido, pues creo que fueron seteadas antes de darle forma a la actual separación entre app y local-data.

fer@eee:~/dev/opacmarc/svn$ svn propget -R svn:ignore
htdocs/img - bibima*

htdocs/js - bibima*

cgi-bin/pft - bibima*

config - *.cip

cgi-bin - wxis*

bin - agrep*
cisis*
*.pyc

cgi-bin/xis - bibima*

htdocs/css - bibima*

cgi-bin/html - bibima*

util - *.mst
*.xrf
*.n0*
*.l0*
*.cnt
*.ifp
*.tab