Migrando la página de PyAr a MoinMoin

cHagHi — Thu, 26 Jan 2006 03:49:26 GMT

[Actualizado el 05/02/2006]

Hace un par de semanas, motivado por el virtual abandono del sitio oficial de PyAr, y alentado por algunas opiniones que se generaron en la lista de correo, decidí hacer una prueba piloto sobre como quedaría el portal de PyAr basado completamente en un Wiki, más precisamente, en MoinMoin.

Actualización: el portal original en Zope/Plone al que se refiere este artículo, está en http://plone.python.com.ar

Tenía pendiente escribir un poco sobre este tema, porque algunas experiencias y los fundamentos (el por qué) de la migración me parecen interesantes. Pero antes que nada, algunas aclaraciones:

Si no te interesa Python y/o no estás relacionado de alguna manera con PyAr o alguna otra comunidad de usuarios de Python, o no te interesa leer sobre el mantenimiento y la administración de un portal, probablemente podrías pasar este artículo de largo.
Es un trabajo en progreso. Aún no hay nada implementado, ni nada para ver (al menos oficialmente...). Ni siquiera está dicha la última palabra respecto a que este laburo va a terminar reemplazando el sitio actual de PyAr. Bien podría pasar al olvido como un intento. [Actualización: pocos días después de escribir este artículo, finalmente migramos a MoinMoin... y todo esto dejó de ser un trabajo en progreso para ser una realidad :) ]
Las opiniones que expreso acá no necesariamente representan la opinión de PyAr. Digamos que estamos de acuerdo en que el portal necesitaba urgente una renovación (probablemente si no no estaría laburando en esto, y escribiendo este post). Pero en lo que respecta a la necesidad de abandonar Zope y Plone, y cambiar de tecnología, las opiniones están más divididas.
Tengo una opinión personal bastante negativa hacia Zope y Plone, y esto se que es un punto conflictivo. Así que vale la pena aclarar que mi opinión debe leerse en el contexto del portal de PyAr, y nuestras necesidades. Probablemente en otros contextos sean la mejor alternativa que existe. Y también es importante destacar que nunca tuve suficientes motivaciones para aceptar el desafío de escalar la empinada curva de aprendizaje de Zope y ver que hay del otro lado. Por lo tanto, admito abiertamente que en lo que respecta a Zope, están leyendo la opinión de un newbie.

Hay que hacer algo

Cualquiera que entre a la página de PyAr a la fecha de redacción de este artículo, verá que está desactualizada. Muy. Y desde hace mucho. Eso es una porquería, habla mal de nosotros, y no podemos ser una comunidad digna de Python con un portal en ese estado.

Es el producto de muchas horas de esfuerzo, está hecho con la colaboración y la buena voluntad de mucha gente, y tiene detalles de diseño y contenidos que están realmente muy bien. Pero tomándolo como un todo, en su estado actual, es vergonzozo :(

¿Por qué se llegó a esto?

Por un lado, porque la herramienta de comunicación principal de PyAr es la lista de correo. Esto es algo que se dió así. Incluso podríamos debatir si esto es una consecuencia de que el portal no sea bueno, y entrar en una recursión interesante ;)

Pero en concreto, lo que pasa en PyAr, pasa por la lista. Eso hace que prácticamente ninguno de los miembros activos ingrese al portal como para decir "uy! esto está completamente desactualizado!".

La segunda causa, es la dupla Zope + Plone. Es innecesaria- y extremadamente compleja para nuestros propósitos. Normalmente, la gente que tiene tiempo de dedicarse al contenido del portal, no tiene el conocimiento para lidiar con Zope (o Plone). Cuando intenta lidiar con él, se encuentra con que algo que debería llevar 5' se transforma en una tarea de 30', con la ayuda de Google, y mucha buena voluntad. Obvio, esto es porque esa persona no conoce a fondo la herramienta... pero eso nos lleva al segundo grupo de gente: La gente de PyAr que sabe de Zope, no tiene tiempo para administrarlo, o no tiene acceso a hacerlo (por restricciones de seguridad).

Resultado: Para los que quieren aportar contenido, Zope y Plone representan una barrera de entrada demasiado alta.

¿Cómo resolver el problema?

Basándonos en lo anterior, y suponiendo que el diagnóstico sea correcto ;) hay dos frentes para atacar:

Lograr que el portal gane en contenidos, para que parte de la dinámica del grupo pase por ahí, y sea más fácil mantenerlo integrado a nuestras actividades. De esa forma, para nosotros se transforma en una herramienta actualizada, y el efecto colateral es que los visitantes ocasionales se encuentran con un portal más digno :)
Hacer que sea fácil para todos (o la gran mayoría) de los miembros de PyAr generar contenido, de manera que cuando alguien tiene 10' de su tiempo para realizar un aporte, pueda invertir el 100% de su tiempo en eso, en el contenido, y no en pelear con la herramienta.

... y miren que loco como están relacionados los dos cursos de acción. Son un hermoso círculo virtuoso.

Solución: pongamos un Wiki

Quizás no sea la única alternativa. Pero estamos casi convencidos que es la mejor. ¿Por qué? Porque está pensado precisamente para que la generación y la administración del contenido pase por un grupo de gente amplio, sin tener que depender de roles de editores o revisores o escritores. Después se verá que páginas del wiki requieren algún permiso especial para tocarse, o cuales son los requisitos mínimos para poder editar contenido (¿registrarse? ¿ser miembro de la listsa?), pero lo importante es que nos da la posibilidad de tener un camino rápido y dinámico para generar contenido.

¿Por qué no ZWiki?

El portal actual tiene un wiki (ZWiki), montando sobre Plone (¿o es sobre Zope? Vaya uno a saber... :p)

De hecho, gran parte del contenido está ahí, y en su momento, ayudó bastante a destrabar la primera paralización que sufrió el portal (si! La historia de PyAr es corta, pero ya vamos por la segunda crisis de portal :p)

El tema es que necesitamos un Wiki, sin todo el resto. Sin estar embebido en la estructura de portlets y permisos y parafernalia de configuración de ninguna otra cosa. Porque aún cuando se pudiera personalizar más la combinación de Zope + Plone + ZWiki para ocultar la complejidad del resto, y todo aquello que no usamos, la realidad es que no hay nadie que reuna los conocimientos, las ganas y el tiempo necesario.

¿Por qué Python Powered?

Cuando empezamos a proponer alternativas, surgió que en PyAr hay dos opiniones claramente divididas respecto al lenguaje en el que esté desarrollada la herramienta que usemos:

Los que no nos importa tanto, y consideramos que lo importante es la funcionalidad que brinde la herramienta y su usabilidad;
Los que tienen una opinión cuasi-religiosa respecto a que el portal de PyAr tiene que ser Python Powered, y están dispuestos a iniciar una cruzada para defender su causa :p

Esto hizo que MediaWiki (realizado en PHP), que para mí era la mejor alternativa (inspirado en las experiencias recientes de los portales de Mono, Hula, The Tango Desktop Project, Beagle, ...) quedara descartado.

PyAr es una comunidad, y la idea es sumar, no dividir. Así que aquellos a quienes nos daba casi lo mismo, nos decantamos por la alternativa de Python. Si de acercar posiciones se trata... era el camino lógico, ¿no?

Más allá del argumento "religioso", Lucio Torre dió después un argumento mucho más sólido: Si en algún momento nos topamos con un bug de la herramienta, o queremos extenderla, o queremos customizar algo que requiera meter mano en el código, o queremos contribuir en algo con el proyecto... más vale que esté hecho en Python, porque somos un grupo de usuarios de Python, y se supone que nos gusta mucho más echar código en ese lenguaje que en PHP o Ruby o cualquier otra cosa.

Y eso terminó de convencerme: Si estaba dispuesto a invertir tiempo en armar una prueba piloto en mi casa, en mi PC, con alguna otra herramienta, más vale que fuera en Python.

¿Por qué MoinMoin?

Acá no hubo que pensar tanto... el wiki oficial de Python corre desde hace años (¿desde siempre?) en MoinMoin, Python Brasil usa MoinMoin, y en popularidad, historia y cantidad de implementaciones, Wiki + Python = MoinMoin. Punto.

También llegamos a evaluar Trac, pero lo descartamos porque si bien posee un Wiki, no es un wiki. Está orientado a la administración y documentación de un proyecto de software, y no a armar un portal comunitario. Por más que parece un buen producto, y está de moda, no estábamos seguros como se adaptaría a nuestro caso de uso. Todavía no está tan maduro. Y lo que terminó impidiendo que al menos le diéramos una oportunidad, es que solo está en inglés. Oficialmente no hay versiones internacionalizadas, y los esfuerzos de internacionalización están en el ToDo, recién para después de la versión 1.0. Y más vale que no íbamos a poner el portal de Python Argentina en inglés...

Sé que hay algunos productos derivados de MoinMoin. Probablemente haya más alternativas... y lo que es seguro es que no las evaluamos todas. Pero allá fuimos... a por MoinMoin.

So far, so good

La instalación resultó más compleja que la de MediaWiki, pero está muy bien documentada. En general, la doc de Moin es muy buena.

Por lo demás, fue cuestión de migrar contenido (como era poco, y el markup de ZWiki no es tan diferente al de MoinMoin, lo hice manualmente), y reorganizarlo. Podría haberse automatizado, pero fue una buena oportunidad de repasar todos los textos, corregir errores, e ir definiendo la nueva organización sobre la marcha.

A medida que fui jugando, descubrí o aprendí a valorar mucho algunas características:

No hay base de datos. Las páginas son archivos de texto, con el mismo markup en crudo, con los mismos nombres, y con la misma estructura jerárquica. No solo facilita la administración (no hay que lidiar con un RDBMS), sino que abre la puerta a acceder de manera transparente a los datos desde afuera del wiki, para mantenimiento, backup, o para procesos masivos, como agregar o sacar algo de todas las páginas.
Moin soporta múltiples configuraciones: Personal, CGI, basada en Twisted, con lo cual nos da flexibilidad en los requerimientos del hosting, y nos permite jugar con diferentes configuraciones en caso que tengamos que escalar o arreglar algún tema de performance.
Es muy extensible. Hay muchas "macros" estándares. Hay todo un juego de macros populares, que tienen bastante historia y están probadas y siguen el desarrollo de MoinMoin. Y lo que es mejor, las extensiones son muy fáciles de escribir (bah, al menos la API es sumamente sencilla). En caso de querer realizar algo particular, que no esté cubierto por ninguna macro existente, no sería complejo escribir nuestra propia macro.
El markup estándar es sencillo de aprender. Pero además, hay parsers para escribir en reStructuredText, coloreo de sintaxis de Python, y la posibilidad de generar un documento DocBook a partir del wiki!!! Eso está buenísimo... se me ocurre que el día de mañana, si necesitamos generar desde PyAr alguna doc formal, podemos escribirla entre todos, y luego generar el DocBook estándar.

Lo único que todavía necesita un poco más de trabajo, es la internacionalización, al menos en castellano. Pero bien podría ser la contribución de PyAr a MoinMoin: Completar la traducción de las páginas de ayuda que faltan, traducir algunos strings de la interfaz que están en inglés, etc.

Estética

Uno de mis mayores prejuicios respecto a MoinMoin era que todos los wikis que había visto, están casi sin personalización, basados en dos o tres "themes" estándar, bastante crudos. Y yo estaba obsesionado con la estética que Garrett LeSage y otros le habían dado a los sitios que mencionaba más arriba, basados en MediaWiki.

Pero después descubrí que esa personalización de MediaWiki no es sencilla, no está documentada... y yo no soy Garrett. Y que es posible personalizar a fondo MoinMoin también. Con esfuerzo, pero es posible.

Ya dimos los primeros pasos, y no fue tan complejo: Crear un nuevo tema, "pyar", basado en el estándar "modern", limpiar el layout, mejorar las fuentes, personalizar un poco los colores. Con el tiempo, será cuestión de ir agregando detalles.

Conclusión

La renovación del portal de PyAr es posible, y está en marcha. Hay pilas de mucha gente para tener un portal mejor, y varias personas se engancharon con la idea, y hasta estuvieron jugando con el portal de prueba.

El feedback recibido hasta ahora fue positivo, a todos les está gustando. MoinMoin está probando ser una mejor alternativa que Zope + Plone para nuestras necesidades, aunque por ahora es casi una hipótesis... habrá que ver, si migramos, como terminan dándose las cosas en la práctica, con el sitio real, y con el tiempo.

Si todo sigue como hasta ahora, en pocos días más estaríamos en condiciones de hacer la migración definitiva. :)

el blog de cHagHi (Publicaciones sobre moinmoin)