Drush para Drupal, el viejo Make y el moderno Composer

• Realizar descargas del core de Drupal y de módulos contribuidos desde Drupal.org

• Traer código desde repositorios SVN, Git o Bzr.

• Traer parches, temas,librerías externas y perfiles de instalación ya configurados

El flujo de trabajo corriente es generar un fichero .make del proyecto Drupal en el que estemos trabajando a través de drush generate-makefile proyecto.

Composer

Composer es básicamente un gestor de dependencias que trata con paquetes y librerías. Anteriormente la gente relacionada con PHP tenía que ir sitio a sitio a buscar los recursos necesarios para sus proyectos sin poder contar con un gestor de dependencias propios como el bundler de Ruby o el npm de Node.js. Inspirado en estos, se creó hace un tiempo Composer.

Básicamente podemos decir que lo que hace este gestor de herramientas es recorrer el árbol de dependencias de un proyecto de manera completa para ir a buscar todas las necesidades existentes (directas e indirectas), comprobar versiones y asegurarse de las compatibilidades de estas.

Como comentaba hace unos párrafos, es interesante gestionar todo lo relacionado con Drush desde el propio Composer:

$ composer global require drush/drush:8.*

Ahora pasamos de nombreproyecto.make a composer.json

Conclusiones: ¿Cuál es el juego?

Gestión de dependencias

Composer localiza, maneja y comprueba el estado y las versiones de las dependencias. Se asegura de las compatibilidades con el proyecto. Drush en cambio no afronta el análisis de estado y versiones, lo que resulta un handicap al trabajar con librerías basadas en PHP que queden fuera del ecosistema propio de Drupal . Punto para Composer.

Parches y librerías

Composer da soporte a la gestión de parches y librerías externas, pero es a través de plugins añadidos y en el caso de Drush Make esta es una función básica de la herramienta. Para los parches hay que manejarse con algo como https://packagist.org/packages/cweagans/composer-patches (por ejemplo) o cuestiones de ubicación correcta de ciertas librerías asociadas a módulos, como en este plugin https://github.com/generalredneck/drupal-libraries-installer-plugin

En definitiva es necesario conocer bien que plugin necesitamos para según que, dónde se encuentra y configurarlo. Punto para Drush Make.

Madurez

Está claro que esto de la madurez de una y otra herramienta puede llegar a ser un debate complejo o al menos, difícil de asentar teniendo en cuenta que nos estamos manejando en términos abstractos. En cuestiones de edad, parece existir una diferencia significativa: Drush fue lanzado en mayo de 2007 y Composer en marzo de 2012. Uno y otro tienen más de nueve años y algo más de cuatro años respectivamente. Casi el doble de vida útil de un proyecto por parte de Drush. Es cierto que Drush tiene sus repositorios en Drupal.org y Composer para Drupal packagist.drupal-composer.org , que hay algunas limitaciones en cuanto a disponibilidad de existencia de proyectos en los repositorios de uno y otro lado, pero no es nada que no resulte insalvable en realidad.

En cuestiones de ritmo, es seguro que Composer superará a Drush Make muy pronto, ya que en términos de comunidad de desarrollo, mientras que Drush es una herramienta específica para Drupal con solo una comunidad detrás participando de su desarollo, Composer es utilizado de momento por las siguientes comunidades: Symfony, Laravel, CodeIgniter, CakePHP, Fuel y por supuesto Drupal (a partir de su versión 8).

Homogeneización

En general, parece que hay un par de claves que tenemos también que balancear: por un lado, la propia estructura de directorios interna de Drupal 8 en adelante ya viene articulada para una correcta integración con Composer. Por otro lado, se produce también una “homologación” con el resto de comunidades basadas en PHP, al usar una misma herramienta para gestionar dependencias. Esto es importante desde el punto de vista de la integración con otras tecnologías (punto fuerte de las claves de Drupal 8) ya que en realidad Drush siempre fue una herramienta construida ad-hoc para Drupal exclusivamente, y no podemos dejar de tener esto en cuenta: Composer es integración.

Conclusión

Composer ha alcanzado cierta paridad en capacidades con respecto a Drush Make. Composer es más moderno, más “estándar”, más transversal y está mejor preparado para proyectos que usen orientación a objetos.

Drush trae problemas en sus instalaciones desde repositorios oficiales por defecto en Ubuntu, y hay que modificar fuentes para integrar otros repositorios y gestionar paquetes en versiones más actualizadas. Con sus incompatibilidades en versiones si queremos trabajar en proyectos Drupal de diferente versión casi mejor gestionarlo desde Composer, que además es la herramienta recomendada para trabajar con Drupal 8, creando varios directorios, alias y realizando instalaciones de versiones diferentes de Drush en cada una.

Además en cuestión de gestión de dependencias parece ser más eficiente. A día de hoy, parece ser que Composer es ya el presente y será el futuro.

Idea

Como Drupal 8 requiere la última versión de Drush y esta conflictea con versiones antiguas de Drupal, mejor organizarse. Si tienes una especie de “Carglass” de Drupal y almacenas en tus entornos hasta proyectos basados en Drupal 6, lo mejor será tenerlo todo compartimentado y habilitar un pequeño sistema “switch” ad-hoc para versiones de Drush y todo vía composer, manteniendo una versión “global” a nivel de sistema para trabajar con Drush y el resto en sus respectivos directorios.

composer global require drush/drush:7.*

mkdir ~/drush8
cd ~/drush8
composer require drush/drush:dev-master

mkdir ~/drush7
cd ~/drush7
composer require "drush/drush:7.*"

mkdir ~/drush6
cd ~/drush6
composer require "drush/drush:6.*"

Poner un “alias” a los directorios

alias drush6='~/drush6/vendor/bin/drush'
alias drush7='~/drush7/vendor/bin/drush'
alias drush8='~/drush8/vendor/bin/drush'

Comprobar que todo va bien:

drush6 --version
drush7 --version
drush8 --version

Y a partir de aquí trabajar desde los alias

drush7 sql-sync
drush6 pm-download views