Re: [Health-es] Sugerencias sobre el instalador

[Luis González]

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

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

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.

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.