Composer y como cambió la comunidad PHP

Una de las cosas que he leído bastante y me he dado cuenta de acuerdo a mi experiencia como desarrollador o en conversaciones con colegas del mundo PHP, es que existió un tiempo en que trabajar en este lenguaje significaba la mayoría del tiempo re-inventar la rueda una y otra vez. Quizás muchos tenían sus pequeñas librerías que los ayudaban en tareas comunes o muchos otros buscaban soluciones en sitios como PHPClasses, HotScripts o SourceForge para no perder el tiempo en cosas que ya estaban hechas o ver como se hacían y realizarlas ellos mismos. Las típicas instrucciones “descargue el ZIP, descomprima e incluya la librería a su código” ya sea para instalar o actualizar eran pan de cada día.

El termino package no era ampliamente utilizado en la comunidad y aquellos que los utilizaban contaban con una lista provista por PEAR, el cual vendría siendo el repositorio oficial de paquetes para PHP. Esto, hasta la aparición de Composer – gracias a Dios -.

LA LEYENDA ‘PEAR’

Cuenta una leyenda que en algún tiempo existió algo llamado PEAR en el lejano reino de PHP4, un administrador de paquetes que prometía mucho y facilitaba las cosas a los usuarios. Eran tiempos dorados – dicen -, con un amplio uso de PHP en la web, siendo uno de los reinos más poblado de todos.

PEAR era una comunidad grande, con cientos de usuarios aportando con sus paquetes bajo un mismo estándar de código. Los usuarios lo utilizaban para crear magníficos proyectos reutilizando código y ahorrando tiempo de desarrollo. Contaba con cientos de paquetes a la espera de ser descargados y utilizados. Pero poco a poco esa comunidad fue generando un elitismo interno, provocando el estancamiento en del desarrollo y actualización de paquetes debido a que los que querían aportar “no eran lo suficientemente buenos en el lenguaje”.

PEAR hizo mucho por la comunidad, pero pasó el tiempo y ésta se empezó a quejar debido a que se volvió anticuado de utilizar y no cumplía con las expectativas actuales de desarrollo, apareciendo problemas como:

  • No servía para trabajar con muchos proyectos a la vez en una máquina. Por ejemplo X proyecto necesita de la librería Z en su versión 1.05. Todo bien hasta ahí, pero X fue desarrollado hace 3 años atrás y ahora deseas montar tu proyecto Y que utiliza la librería Z en su versión 3.5. ¿El problema?: PEAR no permite tener dos versiones de una misma librería en la misma máquina. PEAR trabaja a nivel global.
  • Programas con código que estaba en tu máquina local y fácilmente te olvidabas de aquellas librerías que son parte del proyecto y cuando ibas a hacer deploy simplemente era un loop de correr el proyecto, ver el error, instalar la librería faltante, ver el proyecto, ver el error, instalar la librería faltante. ¿Y qué pasaba con esas librerías que son ocupadas en casos muy puntuales?. Se olvidaban.
  • La documentación de los paquetes era paupérrima en muchos casos.
  • Aportar con nuevos paquetes era difícil, debido a los exigentes requisitos para poder ser parte de esa “comunidad”. Por lo mismo los usuarios crearon sus propios canales, lo que impedía que otros pudieran buscar en la página de PEAR ese paquete en especial.
  • La mayoría de los paquetes quedaron abandonados y nunca fueron actualizados a nuevas versiones de PHP ni fueron resueltos sus bugs.

La comunidad PEAR reaccionó a algunos de estos problemas, viendo que la verdad no estaban generando la atracción suficiente y que la herramienta no estaba siendo utilizada por los usuarios – ni nuevos ni antiguos -. En respuesta a esto, desarrollaron PEAR2 y Pyrus. La primera era la nueva versión del repositorio de paquetes y la segunda el nuevo instalador – antes llamado PEAR, al igual que el repositorio -. Ahora estaba programado en PHP5, algo que hace mucho tiempo debieron haber hecho. Al ser “el” repositorio de paquetes de PHP tuvieron que haber sido los primeros en mudarse a la nueva versión del lenguaje, pero demoraron casi 5 años en realizarlo. Los paquetes fueron publicados a GitHub intentando socializar el desarrollo de éstos. Permitieron que los paquetes fuesen instalados a nivel de proyecto, si necesidad de instalarlos globalmente. A pesar de estos y más esfuerzos, llegaron tarde, y la comunidad ya había dejado a PEAR en el olvido, quedándose sin un gestor de paquetes para el lenguaje.

Hoy en día la comunidad PEAR existe, pero es como un pueblo fantasma. Ingresando al sitio de PEAR2 podemos ver que en todo el 2013 no han habido actualizaciones ni nuevos paquetes y lo que encuentro peor, en lista de issues en GitHub de Pyrus hay bugs declarados hace dos años que aún no son resueltos. Lo extraño es que los paquetes para la primera versión de PEAR siguen siendo levemente actualizados, en desmedro de una supuesta y más moderna solución como PEAR2 y Pyrus.

EL CAMINO HACIA COMPOSER

Con el fuerte auge de Ruby on Rails en 2006, PHP empezó a caerse a pedazos. Los malos comentarios hacia la comunidad y el lenguaje volaban por la red, mirándolo como la oveja negra de los lenguajes para el desarrollo web.

En ese entonces aparecieron frameworks como CodeIgniter, Symfony y CakePHP, ofreciendo a la comunidad un desarrollo ágil y rápido, sin preocuparse por re-inventar la rueda, si no que sólo debían preocuparse en el desarrollo de su aplicación. Cosas como el manejo de sesiones, seguridad, identificación, plantillas, se daban por hecho. Era algo muy tentador y lo que PHP necesitaba para que Ruby on Rails no terminara matando la comunidad.

Los framework eran algo nuevo para PHP y muchos no dieron el pie para probarlos por muy llamativos que se veían – soy uno de ellos -, era como tirar gran parte de tu conocimiento a la basura y empezar de nuevo: “para que quiero un sistema de seguridad si yo lo se hace o ya lo tengo creado”.

Estandarizaron el código, claro, con su propio estilo para cada framework, pero aún así era un buen paso y por fin veíamos códigos escritos con cierto estándar. Implementaron su propio repositorio de paquetes, donde la comunidad podía crear una solución a un problema en común y compartirlo para que otros la utilizaran en otros proyectos. Si querías traspasar un paquete creado para CodeIgniter a Laravel se debía adaptar el código para que encajara con el ambiente y  el estilo de código de Laravel. Todo esto llevó a que nuevamente la comunidad PHP se estuviese dando vueltas en círculo, buscando respuestas a los mismos problemas de manera independiente, sin lograr unificar las soluciones y que éstas sean ejecutables en cualquier ambiente. Claro, teníamos frameworks que tenían hermosas funcionalidades, pero muchas de las tareas que las hacían posible eran desarrolladas una y otra vez para cada framework. Tiempo perdido.

¿Y ahora, quién podrá defendernos?.

EL NACIMIENTO DE COMPOSER

Composer nace desde la comunidad de Symfony, como solución a los paquetes y sus dependencia externas. El problema era el siguiente: querías desarrollar un paquete para el framework, pero éste dependía de una librería externa de Symfony, como DoctrineAl no ser parte del framework, debías entregar tu paquete en conjunto con Doctrine. ¿Pero que pasa cuando deseas actualizar Doctrine debido a un bug de éste?. Si eras el desarrollador debías descargarlo y volverlo a adjuntar a tu paquete y luego publicarlo para que lo descarguen nuevamente o solicitar que los usuarios descarguen la nueva versión de Doctrine por su cuenta. Poco práctico, no puedes pasar la tarea de actualizar las dependencias al usuario o darte el tiempo de hacerlo tú mismo cada vez que pase algo como esto.

Es así como Nils Adermann y Jordi Boggiano – y muchos otros contribuidores actualmente – crearon Composer. Un administrador de paquetes flexible, simple y que se encarga de la administración de dependencias con su propio repositorio llamado Packagist. Está fuertemente inspirado en npm de node.js y Bundler de Ruby, entregándonos las siguientes ventajas:

  • Trabaja a nivel de proyecto, por defecto nunca instalará algo de manera global – como lo hace PEAR -.
  • Soporta el estándar PSR-0.
  • Nos permite auto-cargar nuestros paquetes en nuestro proyecto.
  • Es muy simple crear y subir un paquete al repositorio. No hay requisito alguno, cualquier puede hacerlo.
  • La mayoría de los paquetes trabajan con GitHub, lo que permite desarrollo social, todos pueden aportar a un paquete.
  • Muy simple de instalar y utilizar.

El primer proyecto el cual utilizó Composer fue Silex en septiembre de 2011, un micro-framework PHP basado en los componentes de Symfony, siendo el mismo día en que Symfony implementó el uso de Composer. Luego fue cosa de tiempo para que otros frameworks lo implementarán.

COMO COMPOSER CAMBIÓ LA COMUNIDAD PHP

Como visión propia puedo asegurar que Composer ha cambiado y está cambiado la comunidad PHP. Si bien en su inicio era una solución que iba a ser desarrollada exclusivamente para Symfony, finalmente terminó siendo realizada para toda la comunidad, permitiendo que el lenguaje se vuelva nuevamente interesante, generando un segundo empujón luego del nacimiento de cientos de frameworks en el año 2006.

Composer hizo bien las cosas, y esto ha provocado un aumento en el autoestima de la comunidad. Las cosas están empezando a funcionar como debieron ser desde hace mucho tiempo, promoviendo estándares como PSR-0 en el desarrollo de paquetes, permitiendo una auto-carga de éstos a tu proyecto, sin necesidad de realizarlo de forma manual en algunos casos.

PEAR pasó al olvido y muchos llaman Composer como el PEAR-Killer, pero la verdad es que no lo ha matado, PEAR está muerto hace mucho rato y podríamos llamarlo suicidio. Es por lo mismo que la comunidad simplemente se olvidó de él. En la invasión de frameworks de 2006 ninguno de ellos optó por trabajar con PEAR, si no que cada uno creó su propia solución. Ni Zend, con su framework – la empresa icono de PHP – utiliza PEAR. Hicieron el intento de revivirlo, pero ese intento quedo a medio camino y ya no hay nada que puedan hacer.

Muchas veces envidié ver lo “bonito” que se veía desarrollar en otros lenguajes y me alegra hoy decir que PHP está a la altura de un desarrollo ágil, y bonito claro. La famosa re-invención de la rueda tiende a desaparecer y no sólo en proyectos personales si no que a nivel de frameworks está sucediendo lo mismo. Es cosa de ver el caso de Laravel que trabaja como componentes de Symfony, ahorrando un montón de código y horas en cosas que ya están solucionadas, centrándose en el desarrollo de otras herramientas en las cuales quiere destacar y delegando tareas que no encuentra necesarias volver a re-inventar.

Poco a poco el uso de Composer se va expandiendo y se convierte en una tendencia, que más que tendencia, es algo que tiene que suceder. Proyectos tan grandes Drupal ya lo están utilizando y ya vendrán otros como Joomla, WordPress o Prestashop. Veremos una comunidad dedicada a crear soluciones a problemas comunes, para que éstas sean implementadas en nuestros proyectos.

AGRADECIMIENTOS Y REFERENCIAS

Gracias a Jordi Boggiano – uno de los creadores – y a Igor Wiedler que amablemente respondieron mis dudas sobre el origen de Composer en el chat IRC de la comunidad.

Referencias:

Anuncios

One comment

Deja un comentario (puedes utilizar Markdown)

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s