El lío de los plugins de Symfony

La popularidad de Symfony aumenta cada día, lo que genera muchas cosas positivas pero también crea algunos problemas. El principal problema al que se enfrenta Symfony en estos momentos es el de la gestión de sus plugins.

Hasta ahora, cualquier programador podía crear un plugin y alojarlo en la propia página del proyecto Symfony si cumplía unos requerimientos mínimos. El nombre de todos los plugins estaba formado por el prefijo "sf" y una parte variable que elegía el programador. Si ya existía un plugin con el nombre que tu querías, lo cambiabas ligeramente (como sucedió con sfFeed y sfFeed2).

El primer problema de los plugins tenía que ver con su código: ¿cómo diferenciar el código que es compatible con Symfony 1.0 y con Symfony 1.1? ¿cómo se instala sólo el plugin para Symfony 1.1? ¿cómo se planifica el desarrollo de un plugin para diferentes versiones del framework? La solución a este problema parece que ha sido sencilla y consiste en crear una branch en el repositorio que se corresponda con la versión del framework para la que es compatible (como se puede ver por ejemplo para el plugin sfLucenePlugin).

De todas formas, el principal problema de los plugins tiene que ver con su propio nombre. Se trata de un problema que todavía no tiene solución y que está provocando interesantes discusiones en la lista de correo de programadores de Symfony. ¿Cuál es la mejor política de asignación de nombres para los plugins? A continuación mostramos algunas de las que se han propuesto:

1) Los plugins oficiales se deberían llamar sfXXXX y el resto de plugins deberían tener un prefijo que identifique a su autor (dw para Dustin Whittle, ysf para los de Yahoo!, dd para Dave Dash, ph para Pedro Hernández, etc.). Muchos usuarios han empezado a aplicar esta propuesta y durante la semana pasada se renombraron muchos plugins.

Problemas de esta propuesta:

  • ¿Qué hacer cuando dos nombres diferentes generan el mismo prefijo?
  • ¿Qué sucede cuando el autor original abandona el desarrollo del plugin y lo continuan otros programadores?
  • ¿Qué prefijo utilizan los plugins grandes que están programados por varios voluntarios?

2) Los plugins oficiales se deberían llamar sfXXXX y todos los demás usfXXXX

Problemas:

  • ¿Qué sucede con los plugins no oficiales que por su calidad se convierten en oficiales?
  • El prefijo de los plugins se utiliza a modo de namespace, por lo que si todos los plugins no oficiales comparten el mismo prefijo, se producirían colisiones en las clases.

3) No utilizar prefijos en los plugins

  • Provocaría problemas en los casos en los que el usuario tiene una clase en su modelo con un nombre que coincide con el nombre de otra clase del modelo de un plugin.

La última propuesta ha sido formulada por Fabien Potencier, creador de Symfony, y se basa en el funcionamiento de los plugins de Zend Framework:

  1. Se crean 2 repositorios, uno oficial y otro experimental
  2. Para que un plugin forme parte del repositorio oficial, debe cumplir una serie de requisitos más estrictos que los actuales, pero menos exigentes que los que plantea Zend. El plugin debe ser útil, de código abierto, con buena documentación, con pruebas unitarias, etc. Además, un comité de programadores examina el plugin antes de formar parte del repositorio oficial.
  3. Para formar parte del repositorio experimental, se debe presentar una solicitud formal. En esta solicitud, se explica el propósito del plugin y de esta forma se evita que haya un montón de plugins muy parecidos o plugins que no hacen prácticamente nada.

Como todavía no hay nada decidido, aún puedes aportar tus sugerencias sobre la mejor forma de asignar el nombre a los plugins:

  •  ¿Sería sensato seguir como hasta ahora y dejar que el problema se haga cada vez más difícil de resolver?
  • ¿Se deben seguir renombrando plugins y creando decenas de prefijos diferentes?
  • ¿La propuesta de Fabien es la mejor, aunque reduzca un poco la libertad para aumentar el orden?
  • ¿Cantidad o calidad? ¿Es mejor tener miles de plugins (muchos de ellos malos) o es mejor disponer sólo de decenas de plugins buenos?

Comentarios

  1. Personalmente, creo que es mejor tener plugins muy muy fiables y el resto en fase experimental. Es decir, pocos y muy buenos. Porque a veces no quieres reinventar la rueda y no crear algo que en la comunidad ya se ha hecho pero luego te encuentras que el plugin es insuficiente...

    Me parece muy interesante las propuestas, espero que se decante por una oficial ya que al fin y al cabo lo interesante es tener un estándard.

    elad el 14 de enero de 2008, 10:16:19

  2. Efectivamente, el comentario de "elad" parece que va por buen camino, porque ya no se siguen renombrando plugins con las iniciales de los autores y quizás pronto tengamos una especificación oficial para establecer el proceso de creación y mantenimiento de los plugins.

    Javier Eguiluz el 18 de enero de 2008, 8:56:19

Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente unos meses después de su publicación para asegurar que estos sigan siendo relevantes.

Publicada el

9 de enero de 2008

Etiquetas

Proyectos Symfony destacados

La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.