Re: [Health-es] Sugerencias sobre el instalador

[Luis González]

mmm ok, ya entiendo la lógica. Muchas gracias!

Acabo de crear manualmente un instituto de salud y efectivamente ya no
sale el Traceback.

Lo bueno es que no es un bug :)

Lo de las claves foráneas lo pensaba porque tenía asociado el concepto
de OID con las claves foráneas (investigando un poco ya se que no es
así)

Saludos y gracias por todo!

El 22/7/14, Luis Falcon <address@hidden> escribió:
> Buenas tardes Luis
> On Tue, 22 Jul 2014 09:23:38 -0430
> Luis González <address@hidden> wrote:
>
>> Hola:
>>
>> Perfecto! Mientras más problemas se puedan evitar (o al menos
>> advertir) durante la instalación, mejor.
>>
>> "Cuando haces la instalación la primera vez, creas la compañía y la
>> institución de salud?":
>> Pues no, de hecho salté todos los asistentes para probar el --update,
>> quizás el problema se de por eso. Sin embargo, supongo que a pesar de
>> eso, no debería producirse ese error.
>>
> Por eso :) Es importante terminar el asistente de la compañía y crear
> la institución. Después vas a poder hacer el update sin problema.
>
> A veces está bien no ocultar lo anómalo. Por ejemplo, en este caso, uno
> podría evitar el traceback, pero realmente el problema está en que la
> instalación inicial no se ha terminado, y estás intentando hacer
> un upgrade sobre la misma.
>
> Gracias nuevamente .
>
> Saludos !
>
>> El 22/7/14, Luis Falcon <address@hidden> escribió:
>> > Hola Luis
>> > On Mon, 21 Jul 2014 14:36:10 -0430
>> > Luis González <address@hidden> wrote:
>> >
>> >> Hola Luis.
>> >>
>> >> Me parece que tienes razón, la verdad no había imaginado una
>> >> situación en donde estuvieran ejecutándose más de una instancia
>> >> del servidor (al menos no con el mismo usuario).
>> >>
>> > Perfecto ! Ya pongo el task para verificar que el
>> > archivo /etc/trytond.conf no exista cuando se utiliza el instalador
>> > estándar.
>> >
>> >> Creo que la solución que propones es la mejor, la única desventaja
>> >> sería que no se podría instalar conservando ese archivo, aunque ya
>> >> esa sería una situación inusual.
>> >>
>> >> La segunda mejor solución(a mi criterio) sería fijar la variable
>> >> sólo si el archivo existe.
>> >>
>> >> En otro orden de ideas, creo haber encontrado un bug. Lo he podido
>> >> replicar en instalaciones limpias de GNU Health.
>> >>
>> >> Lo único que hice fue:
>> >> 1. Instalar GNU Health y crear la base de datos.
>> >> 2. Instalar el módulo Health y sus dependencias
>> >> 3. ejecutar:
>> >> ./trytond --update health -d gnuhealth2
>> >>
>> >> Y durante el proceso me arroja este error:
>> >> ------------------------------------------------------------
>> >> Traceback (most recent call last):
>> >>   File "./trytond", line 113, in <module>
>> >>     trytond.server.TrytonServer(options).run()
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/server.py",
>> >> line 123, in run Pool(db_name).init(update=update, lang=lang)
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/pool.py",
>> >> line 151, in init lang=lang)
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> >> line 428, in load_modules _load_modules()
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> >> line 396, in _load_modules load_module_graph(graph, pool, lang)
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> >> line 237, in load_module_graph cls.__register__(module)
>> >>   File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/health/health.py",
>> >> line 678, in __register__ CONSTRAINT
>> >> gnuhealth_hospital_building_institution_fkey;") File
>> >> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/backend/postgresql/database.py",
>> >> line 311, in execute return self.cursor.execute(sql)
>> >> psycopg2.ProgrammingError: constraint
>> >> "gnuhealth_hospital_building_institution_fkey" of relation
>> >> "gnuhealth_hospital_building" does not exist
>> >> ------------------------------------------------------------
>> >>
>> >> No tengo mucha noción sobre el funcionamiento de las tablas de GNU
>> >> Health, pero según tengo entendido, no existen claves foráneas en
>> >> ellas. Imagino que ese "fkey" significa "foreign key".
>> > Sí hay (y muchas :) ). Campos relacionales como el M2O usan claves
>> > foráneas.
>> >>
>> >> Por cierto, este error lo encontré porque estoy haciendo
>> >> modificaciones frecuentes a los módulos, y cada vez que hago un -u
>> >> all, me aparece. Imagino que cuando sucede esto, se interrumpe el
>> >> proceso.
>> >>
>> > Es raro, porque este bloque sólo se debería ejecutar una vez en el
>> > primer upgrade de versiones de GNU Health antiguas, donde el modelo
>> > de institución está vacío.
>> >
>> > Cuando haces la instalación la primera vez, creas la compañía y la
>> > institución de salud?
>> >
>> > Gracias !
>> >> El 21/7/14, Luis Falcon <address@hidden> escribió:
>> >> > Hola Luis
>> >> >
>> >> > On Mon, 21 Jul 2014 10:03:34 -0430
>> >> > Luis González <address@hidden> wrote:
>> >> >
>> >> >> Si el archivo "/etc/trytond.conf" existe, el servidor de GNU
>> >> >> Health fallará cuando se inicie. El servidor intentará
>> >> >> utilizarlo como su archivo de configuración, lo que provocará
>> >> >> un error por no tener permisos de lectura (como le sucedió a
>> >> >> Cecilia), o en el mejor de los casos, se iniciará con una
>> >> >> configuración incorrecta. Esto se puede prevenir colocando la
>> >> >> siguiente línea en el archivo gnuhealthrc: export
>> >> >> TRYTOND_CONFIG="${GNUHEALTH_DIR}/tryton/server/${TRYTOND}/etc/trytond.conf"
>> >> >>
>> >> >> De manera de indicarle explícitamente que, para ese usuario,
>> >> >> utilice ese archivo así existan otros.
>> >> >>
>> >> >
>> >> > Gracias por la sugerencia !
>> >> >
>> >> > Si el archivo /etc/trytond.conf existe es porque se ha dejado de
>> >> > una instalación de Tryton que no debería estar.
>> >> >
>> >> > La mejor solución es seguir la instalación, en un entorno limpio.
>> >> > De lo contrario, aparecerán otros problemas (precedencia de
>> >> > librerías, etc..). Entonces, al final pasamos más tiempo
>> >> > "parcheando" un sistema que no está limpio, y nunca estaremos
>> >> > seguros.
>> >> >
>> >> > Una instalación standard (sistema limpio, sin /etc/trytond.conf)
>> >> > toma el mismo path que la variable de entorno TRYTOND_CONFIG
>> >> > tomaría. El problema está en que esta variable es de entorno. No
>> >> > aplicaría bien en ambientes de desarrollo, con varias instancias
>> >> > por el mismo usuario corriendo en distintos puertos, habría que
>> >> > sobrescribir el valor pasándole como argumento la opción
>> >> > "--config" a cada daemon de tryton que queramos ejecutar.
>> >> >
>> >> > Creo que esta variable de entorno puede generar más problema que
>> >> > solución. Pero me parece muy válida tu sugerencia y de hecho,
>> >> > debemos analizarlo más detalladamente.
>> >> >
>> >> > Lo que me parece que deberíamos hacer, independientemente de la
>> >> > decisión final sobre la variable, es verificar en la instalación
>> >> > que el archivo "/etc/trytond.conf" no exista. Si existe, la
>> >> > instalación debe parar y advertir de una posible instancia previa
>> >> > de Tryton que genera conflictos.
>> >> >
>> >> >
>> >> > Gracias !
>> >> >
>> >> >> El 17/7/14, Luis González <address@hidden> escribió:
>> >> >> > Al intentar acceder al grupo "Administración" (Usuarios ->
>> >> >> > Grupos -> Administración) me aparecía un error. Cada vez que
>> >> >> > lo intentaba, me sucedía lo mismo. Sin embargo, reinicié el
>> >> >> > cliente y ya no puedo reproducirlo.
>> >> >> >
>> >> >> > Por fortuna, copié el traceback, aquí va:
>> >> >> > Traceback (most recent call last):
>> >> >> >   File "/trytond/protocols/jsonrpc.py", line 125, in
>> >> >> > _marshaled_dispatch response['result'] =
>> >> >> > dispatch_method(method, params) File
>> >> >> > "/trytond/protocols/jsonrpc.py", line 158, in _dispatch res =
>> >> >> > dispatch(*args) File "/trytond/protocols/dispatcher.py", line
>> >> >> > 158, in dispatch result = rpc.result(meth(*c_args,
>> >> >> > **c_kwargs)) File "/trytond/model/modelsql.py", line 638, in
>> >> >> > read getter_result = field.get(ids, cls, fname, values=result)
>> >> >> >   File "/trytond/res/group.py", line 31, in get
>> >> >> >     ids.remove(id_)
>> >> >> > AttributeError: 'tuple' object has no attribute 'remove'
>> >> >> >
>> >> >> > No se si sea importante, pero igual lo informo por si a caso.
>> >> >> >
>> >> >> > Si encuentro la forma de reproducirlo, avisaré
>> >> >> >
>> >> >> > El 16/7/14, Luis González <address@hidden> escribió:
>> >> >> >> Excelente!! Muchas gracias... :)
>> >> >> >>
>> >> >> >> El 16/7/14, Luis Falcon <address@hidden> escribió:
>> >> >> >>> Hola !
>> >> >> >>> On Wed, 16 Jul 2014 16:50:17 +0100
>> >> >> >>> Luis Falcon <address@hidden> wrote:
>> >> >> >>>
>> >> >> >>>> Buenas tardes Luis
>> >> >> >>>> On Tue, 15 Jul 2014 21:34:04 -0430
>> >> >> >>>> Luis González <address@hidden> wrote:
>> >> >> >>>>
>> >> >> >>>> > Buenas tardes nuevamente.
>> >> >> >>>> >
>> >> >> >>>> > Tengo 2 recomendaciones más para el instalador.
>> >> >> >>>> >
>> >> >> >>>> > 1. Sí el instalador no se ejecuta exactamente desde su
>> >> >> >>>> > carpeta contenedora, la instalación falla cuando intenta
>> >> >> >>>> > copiar los módulos. Esto se puede prevenir fácilmente
>> >> >> >>>> > cambiando la línea: INSTDIR="$PWD"
>> >> >> >>>> >
>> >> >> >>>> Es que se debe ejecutar desde su carpeta.
>> >> >> >>>> > por:
>> >> >> >>>> > INSTDIR=`cd "$(dirname "$0")" && pwd`
>> >> >> >>>> >
>> >> >> >>>> > Esto haría el instalador un poco más robusto
>> >> >> >>>> >
>> >> >> >>>> > 2. En el archivo "gnuhealthrc", se asume que GNU Health
>> >> >> >>>> > está instalado en $HOME/gnuhealth. Si bien esta es la
>> >> >> >>>> > configuración por defecto, esto no siempre será así (como
>> >> >> >>>> > en mi instalación). Además, no siempre se hace
>> >> >> >>>> > referencia al directorio de la misma forma (a veces
>> >> >> >>>> > $HOME/gnuhealth, a veces ${HOME}... ), lo que dificulta
>> >> >> >>>> > hacer algo como un "reemplazar todos". Lo ideal sería
>> >> >> >>>> > que estuviera en una variable al estilo de:
>> >> >> >>>> > INSTDIR="$HOME/gnuhealth"
>> >> >> >>>>
>> >> >> >>>> Me gusta la idea de INSTDIR. Igualmente, por defecto
>> >> >> >>>> debería siempre apuntar a $HOME/gnuhealth .
>> >> >> >>>
>> >> >> >>> Hecho en
>> >> >> >>> http://hg.savannah.gnu.org/hgweb/health/rev/096774c2abf3
>> >> >> >>>
>> >> >> >>> Uso GNUHEALTH_DIR para no confundirla con ${INSTDIR} del
>> >> >> >>> instalador
>> >> >> >>>
>> >> >> >>> Gracias !
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>> Lo aplicaremos en el default branch .
>> >> >> >>>>
>> >> >> >>>> Gracias !
>> >> >> >>>>
>> >> >> >>>> >
>> >> >> >>>> > De manera que se pueda cambiar fácilmente; o por lo menos
>> >> >> >>>> > que siempre se hiciera referencia al directorio de la
>> >> >> >>>> > misma forma, utilizando la misma nomenclatura.
>> >> >> >>>> >
>> >> >> >>>> > El 14/7/14, Luis Falcon <address@hidden> escribió:
>> >> >> >>>> > > Hola Luis
>> >> >> >>>> > > On Mon, 14 Jul 2014 17:56:40 -0430
>> >> >> >>>> > > Luis González <address@hidden> wrote:
>> >> >> >>>> > >
>> >> >> >>>> > >> Buenas tardes nuevamente.
>> >> >> >>>> > >>
>> >> >> >>>> > >> Les escribo porque tengo algunas sugerencias  para el
>> >> >> >>>> > >> instalador de GNU Health, que podrían facilitar su
>> >> >> >>>> > >> instalación en algunos sistemas. Si este no es el
>> >> >> >>>> > >> lugar correcto para este tipo de propuestas, por favor
>> >> >> >>>> > >> háganmelo saber
>> >> >> >>>> > >>
>> >> >> >>>> > >> He logrado instalar GNU Health 2.6 bajo la versión
>> >> >> >>>> > >> estable de CentOS (Release v6.5 Final). En esta
>> >> >> >>>> > >> distribución, la versión de Python incluída es la
>> >> >> >>>> > >> 2.6.6.
>> >> >> >>>> > >>
>> >> >> >>>> > >>  Debido a que GNU Health necesita una versión >= 2.7,
>> >> >> >>>> > >> y que modificar la versión que viene con el sistema
>> >> >> >>>> > >> produce incompatibilidades, es necesario realizar una
>> >> >> >>>> > >> instalación paralela de Python 2.7. Esto instala el
>> >> >> >>>> > >> binario "python2.7" y (una vez instalado pip) el
>> >> >> >>>> > >> binario "pip2.7.
>> >> >> >>>> > >>
>> >> >> >>>> > >> Mi sugerencia es que el instalador pueda detectar el
>> >> >> >>>> > >> nombre de este ejecutable, similar a como se hace con
>> >> >> >>>> > >> el comando pip (que puede funcionar con "pip", "pip2"
>> >> >> >>>> > >> y "python-pip"). Por ejemplo, se podría colocar algo
>> >> >> >>>> > >> como esto:
>> >> >> >>>> > >>
>> >> >> >>>> > > Muchas gracias por tus sugerencias.
>> >> >> >>>> > > Hay un grupo que  está trabajando sobre la
>> >> >> >>>> > > documentación de la instalación de GNU Health sobre
>> >> >> >>>> > > CentOS, que se incluirá en el Wikibook (en Inglés
>> >> >> >>>> > > incialmente) en los próximos días.
>> >> >> >>>> > >
>> >> >> >>>> > > La versión actual del instalador tiene un "detector" de
>> >> >> >>>> > > algunos sistemas operativos (FreeBSD, GNU/Linux) así
>> >> >> >>>> > > como versiones de distros de GNU/Linux.
>> >> >> >>>> > >
>> >> >> >>>> > > Con esto como base, ya podemos ir "parametrizando" las
>> >> >> >>>> > > instalaciones dependiendo del sabor del OS que
>> >> >> >>>> > > encuentre. Sin duda, tus recomendaciones son más que
>> >> >> >>>> > > bienvenidas y lo estaremos incluyendo tus consejos.
>> >> >> >>>> > >
>> >> >> >>>> > > Saludos !
>> >> >> >>>> > >
>> >> >> >>>> > >
>> >> >> >>>> > >> ------------------------------------------------------------
>> >> >> >>>> > >> local PYTHON_NAMES="python2.7 python2 python"
>> >> >> >>>> > >> PYTHON_NAME=""
>> >> >> >>>> > >> for NAME in ${PYTHON_NAMES}; do
>> >> >> >>>> > >>     if [[ `which ${NAME} 2>/dev/null` ]]; then
>> >> >> >>>> > >>         PYTHON_NAME=${NAME}
>> >> >> >>>> > >>         break
>> >> >> >>>> > >>     fi
>> >> >> >>>> > >> done
>> >> >> >>>> > >> ------------------------------------------------------------
>> >> >> >>>> > >>
>> >> >> >>>> > >> O en su defecto utilizar una variable que almacene el
>> >> >> >>>> > >> ejecutable de python, por ejemplo:
>> >> >> >>>> > >> $PITHON_CMD
>> >> >> >>>> > >>
>> >> >> >>>> > >> De manera que sea más fácil cambiar su valor en todo
>> >> >> >>>> > >> el script.
>> >> >> >>>> > >>
>> >> >> >>>> > >> Por otro lado, en los posibles nombres para el
>> >> >> >>>> > >> ejecutable de "pip" se podría añadir "pip2.7,
>> >> >> >>>> > >> cambiando la línea: local PIP_NAMES="pip pip2
>> >> >> >>>> > >> pip-python"
>> >> >> >>>> > >>
>> >> >> >>>> > >> Por esta otra:
>> >> >> >>>> > >> local PIP_NAMES="pip2.7 pip pip2 pip-python"
>> >> >> >>>> > >>
>> >> >> >>>> > >> Por último, cuando el instalador encuentra que ya
>> >> >> >>>> > >> existe el directorio "/tmp/gnuhealth_installer" no
>> >> >> >>>> > >> debería fallar la instalación, debería borrar el
>> >> >> >>>> > >> directorio (al fin y al cabo es un directorio
>> >> >> >>>> > >> temporal) o crear uno distinto.
>> >> >> >>>> > >>
>> >> >> >>>> > >> Cualquier duda con esta información, no duden en
>> >> >> >>>> > >> preguntar...
>> >> >> >>>> > >>
>> >> >> >>>> > >
>> >> >> >>>> > >
>> >> >> >>>> > >
>> >> >> >>>> > > --
>> >> >> >>>> > > Dr. Luis Falcon
>> >> >> >>>> > > GNU Health
>> >> >> >>>> > > Freedom and Equity in Healthcare
>> >> >> >>>> > > http://health.gnu.org
>> >> >> >>>> > >
>> >> >> >>>> > >
>> >> >> >>>> >
>> >> >> >>>> >
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Salu2
>> >> >> >> Luis F. González V.
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Salu2
>> >> >> > Luis F. González V.
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>


-- 
Salu2
Luis F. González V.