This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Previous revision Next revision Both sides next revision | ||
entorno_de_desarrollo_para_opacmarc [19/05/2009 00:00] |
entorno_de_desarrollo_para_opacmarc [19/05/2009 10:56] fernando |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Entorno de desarrollo para OpacMarc ====== | ||
+ | En esta página describo el entorno que estoy utilizando en mi PC para trabajar en el desarrollo de [[http://code.google.com/p/opacmarc/|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 [[http://svn.collab.net/repos/svn/trunk/contrib/client-side/wcgrep|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''. | ||
+ | |||
+ | * **svn** - Aquí está el código bajo control de versiones. Inicialmente hay que hacer un [[http://code.google.com/p/opacmarc/source/checkout|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 una eliminación completa de ''test-install'' (como los datos locales "normales" viven en ''test-install/local-data'', se pierden al volver a ejecutar ''test.sh''). 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. FIXME mostrar ejemplo. | ||
+ | |||
+ | ===== 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. | ||
+ | |||
+ | FIXME 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). | ||
+ | |||
+ | FIXME Explicar mejor lo que hace el script, y la opción de usar otras bases locales. | ||
+ | |||
+ | ===== Build ===== | ||
+ | |||
+ | cd svn | ||
+ | ./build.sh | ||
+ | |||
+ | FIXME 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). | ||
+ | |||
+ | {{tag>opacmarc desarrollo}} |