[Python-es] Dudas para la publicación (GPL) de una herramienta python de reporting

Jue Dic 16 14:02:09 CET 2010

2010/12/16 Francesc Alted <faltet en pytables.org>

> A Thursday 16 December 2010 12:26:48 Alberto Curro escrigué:
>
>   Me surgen entonces las siguientes dudas:
> >
> >   - Licencia: ¿qué problemas pueden surgir? Estoy desconectado desde
> > hace un tiempo del mundillo del software libre, y ya no me acuerdo
> > si alguno de los módulos usados (4Suite, Reportlab) podría afectar
> > en la publicación de la solución en GPL.
>
> Nosotros elegimos GPL ya que dependiamos de una libreria GPL (creo que
> era pyinotify).  Mi consejo es que, debido a la naturaleza viral de GPL
> la evites si puedes (BSD o MIT van muy bien: sencillas y no pretenden
> imponer la libertad).  Sin embargo, hay que decir que mucha gente se
> siente a gusto con la GPL y la elige a propósito (no es mi caso).
>
>
  Bueno, en esta parte tendría que revisarla. Creo que ni 4Suite ni
Reportlab son GPL...

  Como verás, no miento cuando afirmo que estoy pez y muy desconectado del
mundillo en los últimos 2 o 3 años. Ni se me había ocurrido MIT o BSD y,
sinceramente, pensándolo me gusta más esa filosofía: yo soy libre porque
quiero serlo, tú haz lo que quieras :)

>   - Tecnología: ¿hay soluciones mejores, o más eficientes, para el
> > procesamiento de los XML, XSLT, o mejores que reportlab?
>
> Hombre, hay infinitas :-)  Nosotros por ejemplo no usamos XML para nada.
> Nos inventamos nuestro propio sistema de plantillas para generar los
> PDFs a partir de ficheros texto y un fichero de control (o formato)
> parecido a:
>
>    [task]
>    doctype = Factura amb copia
>    input_encoding = cp850
>    output_name = Factura #123
>    ncopies = 2
>    host = dept-comptabilitat
>    barcode = 123a20080619
>
>    [copy]
>    dir = /el/meu/directori
>
>    [email]
>    from = pdflistings en exemple.com
>    to = paco en ferrer.es
>    subject = Factura #123
>    bcc = factures en exemple.com
>
> Por supuesto, se podian definir plantillas en PDF que se superinponian
> al listado definitivo.  Como ves, no hay XML, así que va como un tiro.
>

  Básicamente usamos XML en su momento porque nos eran sencillo generar los
ficheros XML de entrada (en algún caso trabajábamos contra una solución
propietaria, y el nuestro era un aplicativo externo, simple imposición de
mercado), y también fue una decisión de diseño por la experiencia en ese
momento; estábamos usando XSLT para otras cosas y decidimos continuar por
esa línea.

  Personalmente ahora mismo, si puedo, escapo de XML como de la peste,
aunque reconozco sus virtudes en algunas cosas. Pero bueno, ya que está
hecho, se podría mantener como uno de los soportes a usar, pero no el único
(una de las primeras ideas que se me ocurrió tras verlo el otro día).

>
> >   - Repositorio: ¿qué forja debería usar para publicarlo?
>
> No infinitas, pero muchas, así que tendrás que elegir una.  Yo
> últimamente me he decantado por github.com (aunque eso te obliga a usar
> git como controlador de versiones).
>

  Usar git no tiene mayor problema, porque es el que uso ahora mismo en lo
personal y algo en lo profesional, aparte de SVN.

>
> >   A nivel técnico, el programa habría que revisarlo, dándole
> > posibilidades en cuanto a parámetros de entrada, posibles salidas,
> > una buena refactorización y puesta al día del código (os recuerdo
> > que fue nuestro primer software python, aprendimos python con él...)
> > etc., dado que ahora mismo lo que hace es un proceso de 1 única vía:
> > coge xml -> transforma XSL -> genera RML -> convierte con reportlab
> > -> almacena / imprime.
>
> Aparte de esto, el nuestro también envia por e-mail y fax (aparte de
> otros posibles métodos definidos por el usuario).
>

 Esas posibilidades son muy fáciles de implementar ahora mismo, casi una
chiquillada :)

>
> >   La solución en sí es muy sencilla: coge un fichero XML con datos,
> > lo procesa mediante XSLT, genera un documento RML y lo procesa con
> > Reportlab para generar el PDF final (y enviarlo a impresora o
> > guardarlo). Aparte de reportlab, se usaba 4Suite para el procesado
> > de XML, el motor XSLT y, por supuesto, Reportlab.
> >
> >   Sin embargo, a nivel características era muy potente gracias a
> > Reportlab: se podían generar auténticas "virguerías" a nivel de
> > informes, con la complejidad que se requiriese; sólo deciros que
> > fuimos capaces de conseguir generar, punto por punto, línea por
> > línea, imagen por imagen, todos los tipos de informes usados por 3
> > empresas de distintos tamaños (hablamos de facturas, informes
> > internos, albaranes, etiquetado para logística, etc.) eliminando el
> > uso de los formularios pre-impresos que venían usando, sin que se
> > notase el cambio.
>
> Ahi el nuestro no es tan flexible.  Simplemente se pasa texto a PDF
> diciéndole el tamaño del papel y el número de filas y columnas que iban
> a caber.  Simple, pero efectivo.
>

 Creo que ya lo he dicho, pero si no, ahí va: en nuestro caso era casi un
"must", porque uno de los requisitos era: quiero sacarme el papel de encima,
pero que siga imprimiendo o generando los PDFs igualitos a lo que había en
papel antes. Estuvimos echando un vistazo a posibilidades, y lo único que
parecía cumplir todos los requisitos era reportlab.

>
> >   Eso sí, el mayor problema (y donde se consumía el tiempo) era en la
> > parte del diseño de las plantillas XSL y RML, que no habíamos
> > escrito un software de diseño de las plantillas, y se hacía a mano
> > :)  Por otro lado, no era una maravilla en velocidad: un informe
> > normal tardaba alrededor de 1-1.5 segundos en estar en pantalla, un
> > informe muy largo (más de 20 páginas) o muy complejo... pues
> > imaginaos. La parte más lenta era la de transformación XML/XSLT
> > (incluido el parseo y validación del XML); después de esto iba
> > bastante bien, aunque reportlab en aquel momento no eran tampoco la
> > panacea en velocidad.
>
> Más lento parseando XML que el propio reportlab renderizando?  Creo que
> se me han ido las ganas de trabajar con XML de por vida :-)  Recuerdo
> claramente que nuestro cuello de botella era el reportlab, y se podian
> alcanzar velocidades de varios informes (de entre 1 y 10 pags) por
> segundo.
>

 Ten en cuenta que cuando hablo de un informe "normal" estoy hablando, por
ejemplo, de una factura: escribir los resultados de las queries en XML,
llamada al programa, se cargaban los módulos, validadaba el XML contra el
XSLT y el DTD, parseaba, transformaba, obtenía el RML... a partir de ahí era
renderizado de Reportlab, y aunque no era un guepardo... pues chico, la
impresión era esa, que no era la parte más lenta :)

>
> >    Bueno, creo que ya me he explayado bastante por ahora, para lo que
> > eran unas simples preguntas; cualquier recomendación, consejo,
> > interés en el proyecto, o preguntas, aquí me tenéis. No os cortéis
> > :)
>
> Ya ves que compartimos sinergias :-)  Nuestro paquete es libre, pero no
> está disponible en la red básicamente por el coste de crear el
> repositorio y hacer una página medio decente explicando el asunto
> (cuesta bastante tiempo, y si nadie te lo subvenciona pues...).  De
> todas maneras, si quieres echarle un vistazo, puedes descargar el
> paquete de:
>
> http://www.pytables.org/temporal/pdflistings-0.6.1.dev.tar.gz
>
>
 Esta última parte es la que más me hace pensar: implicará tiempo y energía.
Todavía no sé si debería revisar el código y comenzar el desarrollo antes de
comenzar a trabajar con la forja y subir código, o directamente subirlo
"as-is", comentando las posibilidades en curso, y dejar que los interesados
colaboren a medida que quieran.

 Supongo que la segunda opción es la lógica, pero como siempre he trabajado
en proyectos ya existentes en las forjas, nunca en uno propio (ni desde
cero)...

 PD: Seguro que otros muchos comparten sinergias, pero estamos bastante
ocultos unos de otros (y ocupados)...

> Saludos,
>
> --
> Francesc Alted
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> http://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20101216/9cb702f7/attachment.html>