Composer y Drush en el contexto de Drupal
Como gestionar dependencias en proyectos Drupal 8
Varias personas me han escrito últimamente con fines parecidos: bien para hacerme alguna pregunta sobre la instalación de Drupal 8 a través de Composer, bien para consultarme que hacer ahora para tener Drush asociado al proyecto, bueno y alguna también para maldecirlo todo.
Es curioso pues observando bien, veo que por norma general las consultas suelen venir de compañeros y compañeras que se encuentran en una doble transición: de Drupal Trademark siete a Drupal 8 y del site building con Drupal Trademark a desarrollo de código. Creo que es ahí donde se genera mucha confusión ideal y es justo en ese punto acumulativo de tensiones en el que me gustaría intervenir con este artículo.
Me he animado a recopilar ciertas notas y experiencias y dejarlas estructuradas a modo de artículo consultable con la idea de compartir un poco de conocimiento, dándole una cierta articulación al contenido y siempre y en toda circunstancia con el objetitvo de ayudar a esas personas que se encuentran en esa transición (como yo también lo estuve) y poder hacer un RTFM! cuando llegue el instante :-P.
Lo esencial es -
como siempre- que todo esto le resulte útil a alguien.
Nota:Este artículo tiene más de 6500 palabras, unas cuatro iteraciones hasta el momento (consecutivas ediciones siguientes, hasta mayo de 2019) y Medium dice que hay que invertir al menos veintinueve minutos en leerlo.
En primer sitio y como introducción precisa daremos un paseo por los aledaños de Composer para conocer mejor de que hablamos o bien que es lo que estamos maldiciendo.
1.1- ¿Qué es Composer?
Composer (+)es una aplicación para línea de comandos construida con PHP, lanzada en el mes de marzo de dos mil doce y enfocada a la gestión de dependencias en proyectos basados en el lenguaje PHP. Se basa en otros gestores de dependencias anteriores que estaban disponibles para NodeJS (+ ) o Ruby (+ ) y también procura llevar el mismo concepto a ambientes basados en el lenguaje PHP.
Básicamente, los gestores de dependencias existen para hacernos la vida más fácil en torno a 2 conceptos: automatización (lanzar procesos que funcionen por si mismos) y estandarización (que dichos procesos operen de igual modo unificada), singularmente en el contexto de las librerías de terceros que acostumbramos a usar en nuestros proyectos.
1.2- ¿Para qué sirve?
Básicamente, como anotaba antes, Composer es un gestor de dependencias. Ojo, de dependencias (que podrán ser paquetes o bien otros formatos). Composer trata con bultos, librerías y recursos de diferentes tipos. Pero además, es posible interpretar una instalación inicial como una dependencia inicial por resolver, con lo que también puede emplearse como herramienta de instalación inicial de Drupal. Más adelante vamos a ver cómo.
Podemos decir (de momento), que Composer consiste en dos piezas clave: por un lado una herramienta de línea de comandos para gestionar estas dependencias y también interactuar desde la consola del terminal y por otra parte un repositorio donde se almacenan los paquetes llamado “Packagist.org”
En medio, hay un elemento que los suele conectar a ambos: un fichero
composer.jsonque registra las necesidades de cada proyecto para responder como un registro con herramienta de comandos, que se fundamenta en estas anotaciones para pedir paquetes y dependencias al repositorio. Como complemento a ese archivo .json precedente existe otro llamado
composer.lock.¿En que consiste este último? Es un fichero de registro, como un bloc de notas donde Composer anota la versión precisa que se ha instalado de cada librería. Es la manera que tiene Composer de estabilizar un proyecto en una serie de versiones específicas de sus dependencias. Así, cualquier persona o sistema que se descargue el proyecto tendrá exactamente la misma versión que el resto.
Eh, mas ¿No me habías dicho que para notificar versiones y registrarlas ya estaba el composer.json?
DEVUÉLVEME MI DINERO HDF.
Sí y no. A Composer se le pueden solicitar (por poner un ejemplo), intervalos de versiones y que elija la que quiera (lo vamos a ver en un apartado siguiente). En ese caso, solo tenemos en el .json la indicación de dicha horquilla de valores, mas en el composer.lock vamos a tener la versión específica que al final se ha instalado para el proyecto. ¿Lo ideal? que
composer.jsony
composer.lockviajen unidos al repositorio git del proyecto para que se complementen.
1.3- Uso y funcionamiento
Hasta el instante, Composer está libre para las próximas plataformas y versiones:
Composer desea solucionar la necesidad de tener que averiguar que dependencias de librerías de terceros tiene tu proyecto, sabiendo que es bastante normal el día de hoy día que tus dependencias directas tengan a su vez múltiples dependencias indirectas que no tienes por el hecho de que conocer (ni sus versiones), así que se lanza a resolver el árbol de dependencias del proyecto en cuestión, realizando una instalación -local- de librerías (nada de instalar a nivel global) desde un directorio
vendor/en cada proyecto en el que lo emplees.
¿Esto cómo va?
Una vez instalado en un sistema, Composer deja a través del uso de sus comandos encontrar, descargar y también instalar las dependencias precisas con su versiones requeridas a través de una conexión a un repositorio externo para recursos PHP llamado Packagist (+) que comentamos anteriormente y de donde extrae todos y cada uno de los recursos que precisa. Y para todo ello se apoya en el archivo
composer.json, cuya unidad de registro mínima es la siguiente:
Con la keyword “
require”: anotamos que el proyecto necesita una librería proporcionada por un usuario en una versión determinada. (Y que siendo required, si no está libre Composer no realizará la instalación). Vendor sería algo así como “
proporcionador” (¿vendedor? ¿proveedor?) y proyecto el nombre de la dependencia a solucionar. Veamos la apariencia de un archivo composer.json “
más real”:
Habrás sentido que en el momento en que te descargas y abres un Drupal Trademark ocho hay un archivo llamado composer.json dentro del directorio principal. Bien, hablaremos de ese archivo más adelante pero lo primordial ahora es saber que es un fichero para poder jugar con Composer. De un lado ese fichero y del otro la propia aplicación, que debes instalar en tu máquina.
Existen 2 maneras de instalar Composer: de forma local para cada proyecto y de manera global a través de un acceso general desde cualquier lado de tu máquina y ejecutándolo desde el directorio de cada proyecto o subproyecto. Veamos como discurren estas dos maneras de instalarlo.
2.1- Instalación global / Instalación local
Composer se maneja inicialmente a través de un instalador construido en código PHP que+,+ y proseguir las+. Ok. Básicamente, el plan es que teniendo los recursos y librerías iniciales de PHP ya en tu sistema, te descargues el instalador, lo renombres como un archivo de extensión .php y lances su ejecución (es lo que pasa en el set de instrucciones siguientes que vienen en las instrucciones de descarga e instalación).
Debes tener php listo para usar en consola:
sudo apt-get install php7.0-cli
Desde terminal:
Estas instrucciones precedentes te traen a tu sistema un composer.phar, una suerte de ejecutable PHP que en base a donde lo sitúes tendrá un comportamiento global o local. También puedes descargarte de manera directa el .phar en tu sistema:+
También puede instalarse siguiendo las próximas instrucciones:
curl -sS| php
mv composer.phar /usr/local/bin/composer
chmod +x /usr/local/bin/composer
composer
Localmente:
Para instalarlo localmente, debes lanzar el instalador en el directorio del proyecto. En cuanto se haya descargado el .phar estará disponible para ejecutarse a través de
php composer.pharen la carpetita.
Globalmente:
Para instalarlo de una manera global en tu sistema debes chutarlo en un directorio que sea una parte del
PATH. En los sistemas Unix-based suele caminar por el /bin y desde ahí puede llamarse por línea de comandos. En la siguiente instrucción el afirmamos al instalador de Composer que ubique el composer.phar en /bin y que se renombre como “composer”, para ser invocado desde el prompt:
$ php composer-setup.php --install-dir=bin --filename=composer
Nota:en ciertos entornos hay que explicitar bin como “/bin” en la instrucción precedente. Esto me ha ocurrido hace poco (julio de dos mil dieciocho) administrando un RedHat 6.6 con más años que una playa (2014):
Lo que se puede resumir en 2 instrucciones:
O también puedes descargarlo en cualquier parte y luego moverlo al /bin con el comando mv:
$ mv composer.phar /usr/local/bin/composer
A nivel de empleo, la diferencia estará en que si lo has instalado a nivel local para un proyecto tendrás que usar:
dólares americanos php composer.phar uncomandodecomposer
Y si lo has instalado a nivel global, podrás manejarte desde cualquier sitio mediante:
dólares americanos composer unbonicocomandodecomposer
Y al final si todo ha ido bien, al chutar el comando “composer” por consola, recibirás esta bonita pieza de ASCII-Art y el manual de la herramienta:
2.2- Los comandos de Composer más usuales
De cara a trabajar a diario con Composer, existen unos comandos básicos que es conveniente tener claros. Pueden ser los comandos de Composer más frecuentes y cuanto antes nos familiaricemos con ellos, más experiencia podremos continuar amontonando.
require
El pequeño comando elemental para decirle a Composer que tu proyecto requiere tal o cual dependencia.
El comando require activa la búsqueda, descarga e instalación de dependencias. Veamos que ocurre al pedirle al Composer que instale Drush mediante el comando require:
Y tras el proceso, al abrir el fichero composer.lock, vemos que Drush ha sido instalado y con él, sus dependencias (incluye el Drupal Code Generator):
y si consultamos, vemos que tenemos libre la dependencia:
install
El comando install va al encuentro del fichero composer.json que esté disponible en el mismo directorio donde es ejecutado y se lanza a traer dependencias y a situarlas (generalmente) en el directorio
/vendor
create-project
Este comando es como la suma de ejecutar git clone + composer install: se hace cargo de clonar un repositorio y luego realizar todo el proceso de instalación de dependencias.
El comando
create-projectte deja crear un nuevo proyecto a través de Composer y prepararte toda la mandanga.
El primer argumento del comando es vendor/paquete, el segundo razonamiento es el directorio donde quieres crear el proyecto y también puedes añadir un tercer razonamiento para señalar la versión que quieres instalar de la dependencia. Si no lo señalas, se utilizará la versión más reciente disponible. Además, si el directorio donde deseas crear el proyecto no existe, se creará automáticamente.
Ejemplo:
show
Este comando sirve para listar lo que tienes instalado y en que versión lo tienes. De todas sus opciones, una de las más interesantes en el día a día es la variante espectáculo -lo, que muestra de manera comparada en 2 columnas paralelas tus versiones instaladas y las versiones libres, por si quieres poner al día algunos de tus depedencias. Una forma rápida de obtener una visual de tus recursos.
diagnose
Este comando es una instrucción para ejecutar una revisión rápida del ambiente y revisar en que estado se hallan los requisitos básicos y frecuentes de la instalación de Composer, tras lo que devuelve por pantalla un pequeño informe del resumen de estado, anotando si falta algo o existen inconvenientes con algún recurso:
update
Ok, hace varios apartados explicábamos rápidamente en que consistía el fichero composer.lock. Este fichero registraba la versión específica de una dependencia que el proyecto tenía instalado. Esto en cierta manera marca que, aunque una dependencia publique un nuevo bulto con una versión actualizada, composer.lock se hará el longuis y seguirá con la versión anotada instalada en el proyecto, que queda anclada por este fichero de bloque PERO es posible actualizar a una versión nueva con este comando update, que lanza a Composer a la busca y captura de nuevas versiones (dentro de las limitaciones anotadas en el composer.json, claro), las instala y efectúa la modificación oportuna del registro de esa versión en el composer.lock del proyecto.
self-update
Composer también puede actualizarse a si mismo buscando una versión más moderna. El comando
self-updatecambiará el archivo composer.phar y lo pondrá en su versión más reciente. Si lo tienes montando de manera global es probable que debas utilizar sudo para lanzar la actualización.
search
El comando search
searchbusca el bulto indicado en los repositorios de paquetes que estén declarados en el proyecto. En general sale a buscar la palabra clave introducida por el nombre y la descripción del paquete:
Podemos delimitar la búsqueda al nombre del paquete, dejamos de lado las descripciones de exactamente los mismos para afinar mejor utilizando el parámetro
--only-name
Y si además, lanzamos la consulta (como ocurre con otros comandos en realidad xD) desde un directorio donde no hay un fichero de referencia composer.json, Composer localizará y nos preguntará si deseamos utilizar el más cercano:
remove
El anti-require por si quieres quitar una dependencia del proyecto o bien te has equivocado al lanzar un require. Válido para limpiar y como require-undo:
clearcache
Ocurre de vez en cuando que tras efectuar pruebas e instalaciones, al ejecutar:
Empezamos a localizar errores de instalación. Para curarnos en salud, procedemos a limpiar la caché interna de Composer lanzando la instrucción:
2.3- Ejemplo de empleo con PHPUnit
He querido añadir un ejemplito de empleo Drupal-non-related para completar un tanto estos primeros apartados conceptuales, para darle algo más de sustento y facilitar el que se efectúen ejercicios en tu máquina con Composer. He elegido una secuencia de hace poco, instalando+ (un framework para realizar test de código en PHP) en una máquina. Me ha semejado una forma didáctica de jugar un tanto con Composer.
No pasa nada si rompemos algo: Hemos venido a este programa a jugar.
1- Creamos directorio del proyecto
2- Creamos el fichero de composer para el proyecto:
3- Creamos un fichero composer.json
4- Instalamos dependencias
5- ¿Qué hace Composer?
Como ya hemos dicho, sale a+ a buscar la dependencia, la encuentra en la URL+ y se la trae a la carpeta destino. A propósito, en origen, un paquete en Packagist puede ser un vínculo a un repo de Github, como en este caso de PHPUnit. Esto implica que podemos vincular un repositorio nuestro a Packagist para proveer algún recurso como dependencia por parte de Composer.
De hecho la cruda realidad es que Packagist no en sí mismo un almacén de paquetes, es solo una especie de “
proxy” que registra, filtra y conecta los auténticos repositorios del software que precisamos. Como se ve en la imagen de arriba, en el caso de PHPUnit en realidad Packagist solo está manejando los metadatos asociados desde un recurso externo alojado en Github.
Pero como hemos dicho que íbamos a jugar, ¿Qué tiene esto de ameno? vamos a retorcer un tanto a Composer. ¿Y si le engañamos un tanto? (bueno o nos equivocando declarando una dependencia)…De hecho si le marcamos una versión INVENT:
El pobre Composer se quedará un tanto majara y con mucha cortesía, nos aclarará que nuestros requisitos no pueden ser resueltos, pero que tenemos opciones:
Igualmente, también tiene la cortesía de informarnos a la hora de encontrarse con problemas de compatibilidad en versiones de PHP:
Y una vez elegida una versión compatible, lanzando composer update:
Todo bien, instalado y actualizado en nuestro directorio de pruebas. Ahora a probar (pero eso ya es otra película). Volvamos al hilo argumental que nos ocupa.
Vamos a dar un camino por ciertas anotaciones del día a día que quisiera trasladar en forma de “consejos” para trabajar con Composer. Vamos a repasar primordialmente como efectuar anotaciones con respecto a las versiones de las dependencias, también como hacer las cosas un tanto más ligeras con Composer y por último, vamos a ver un pequeño conector de Composer con Drupal.
3.1- Detallando versiones
Una de las claves funcionales de la mecánica de trabajo con Composer es el hecho de poder apuntarle que dependencia queremos, de que proveedor lo necesitamos y en versión lo pedimos (la terna elemental del empleo de un buen gestor de dependencias). O.K.. Pero en el caso de Composer podemos darle un poco más de juego en el momento de establecer las versiones que solicitamos. Veamos unos ejemplos:
Versiones explícitas
Puedes solicitarle a Composer una versión exacta de una dependencia. Esto pedirá que se instale esta y solo esta versión, lo que puede ser un tanto arriesgado: Si otra dependencia que haya por ahí precisase una versión diferente del mismo recurso a instalar en el mismo directorio (/vendor), el “
resolvedor” (solver) dará un casque y detendrá todo el proceso de actualización o instalación.
Por esto de la posibilidad de enfrentamientos, no es muy común en proyectos de determinada dimensión ver peticiones de versiones precisas. Lo frecuente acostumbra a ser trabajar con rangos y solicitudes más abiertas:
Versiones con comodines
Podemos establecer búsquedas usando comodines (wildcards) en el formato:
Versiones marcadas por un commit específico
Es peligroso y se aconseja cambiarlo cuanto antes se pueda a un tag de lanzamiento (en cuanto esté disponible), mas es posible con Composer pedir una dependencia que hemos probado, sabemos que marcha y que al unísono se encuentra en un desarrollo progresivo en el instante de pedirla. Pero en el momento en el que se encuentra a nivel de repositorio nos viene excelente, así que la queremos instalar hasta un commit específico enviado al repositorio de dicha dependencia. Con Composer es posible añadiendo el hash de un commit específico.
Imaginemos que queremos PHPUnit versión 6.5 y dentro de esta tras un commit que hemos comprobado que nos chuta bien en el proyecto:
Versiones con rango ( con más y menos severidad)
En Composer pueden concretarse rangos de versiones útiles para la descarga, evitando romper las dependencias del proyecto con versiones no compatibles y sobre todo, facilitando las posibles actualizaciones que vayamos acometiendo. Es posible utilizar operadores para establecer rangos, del tipo:
>=1.0 <1.1 >=1.2aunque lo más seguro es emplear los caracteres alternativos para expresar rangos. Estos están vinculados al uso de versionado semántico de las dependencias (formatos x.y.z a sabiendas de que z son parches aplicados e issues menores, y cambios importantes que sostienen compatibilidad y x es una nueva versión completa que incluye incompatibilidades cara atrás).
Para entender bien esta cuestión, hay que tener claro que el versionado semántico representa a través de x.y.z una estructura
mayor.minor.patch,
donde en un mundo ideal (8) no habría trastornos de compatibilidad hasta llegar a una nueva versión de tipo mayor. Bien.
Veamos ciertos ejemplos.
3.2- Haciendo las cosas más ligeras
Una de las formas con la que podemos hacer más ágil el desempeño de nuestro proyecto basado en PHP es manteniendo y mimando todo lo relacionado con las recomendaciones de estilo propias de la comunidad, esto es, el set de especificaciones creadas por la comunidad y recomendadas como buenas prácticas:+,+,+,+
En específico, en la PSR-cuatro, hay+…¿Qué es el autoloader? básicamente una función que busca las clases PHP de manera recursiva, las reúne y las ofrece al resto del proyecto a fin de que estén disponibles para su uso. En este momento de estandarización del código, cada clase PHP es guardada separadamente en un archivo de extensión .php donde nombre de clase y nombre de fichero coinciden. En tiempos precedentes, andábamos poniendo
includeso
requiresal comienzo de muchos archivos para poder emplear sus recursos y funciones pre-determinadas ¿verdad?. Ahora es todo mucho más sencillo, ágil y mantenible(si cumplimos las reglas).
Seguramente al trabajar con ficheros PHP te será familiar el concepto de namespace, o sea, el contexto en el que se define una clase PHP particularmente para a) no colisionar con otra clase que pueda llamarse igual y b) facilitar la inclusión de recursos y dependencias.
Si empleas namespaces en tus proyectos PHP seguramente ya sabrás que están totalmente separados de la estructura de archivos, en tanto que son conceptualmente diferentes. Los namespaces
no tienen nada que vercon las carpetas, son 2 cosas diferentes. Para vincular ambos conceptos, dicho estándar, el PSR-cuatro, permite enlazar los namespaces con directorios de carpetas del sistema de archivos de nuestras máquinas, y ese mapeo es fundamental para establecer el autoloading, o sea, la carga dinámica de clases para poder utilizarlas desde cualquier otro sitio dentro de nuestro proyecto.
El siguiente paso es añadir una clave
autoloadal fichero
composer.jsonutilizando la convención PSR-4:
Y por último ejecutamos este comando, que hará la magia por nosotros:
El comando
dump-autoloadactualiza la información del cargador automático de clases. Este comando es útil cuando añades nuevas clases y no deseas ejecutar el comando
installo
updatey sirve para regenerar el cargador de clases ubicado en
vendor/autoload.phpPero además, es todavía más útil usado con la opción
--optimizeque obliga a generar un mapa de clases. El mapa de clases es una forma de prosperar el rendimiento de nuestro proyecto, puesto que en aplicaciones de determinado tamaño encontrar las clases a través de el cargador resulta pesado y aburrido para los procesos del programa. El mapa de clases lo efectúa de manera mucho más directa. En ese array asociativo, cada clase queda vinculada a su fichero .php de referencia.
En ciertos sitios charlan de mejoras de entre el 20 y el veinticinco por cien del rendimiento al efectuar la optimización a través del mapa de clases.
Cuidadín.
3.3- Cambiando el repositorio de Paquetes a Drupal.org
Este sub-apartado tenía que servir para establecer un puente con el próximo capítulo y comenzar a relacionar ya a Composer con Drupal Trademark y Drush, que es la terna original del presente artículo, así que en el empleo de Composer vamos a ver conectores con Drupal. Se me ha ocurrido ir despejando el camino con una pequeña y rápida aproximación.
Lo primero será reconocer que en Packagist no están registrados todos los módulos disponibles para Drupal, con lo que para ir más allá del core de Drupal Trademark e instalar los recursos que necesitamos en nuestro directorio
/drupal/modules/contrib(lo que viene siendo el set de módulos creados por terceros que utilizamos en nuestros proyectos) debemos mudar el repositorio por defecto que pueda tener el fichero composer.json. Con este fin, desde Drupal Trademark.org se ofrecen un par de repositorios de bultos en+ o+ para conectar vía Composer (si procuras acceder vía web serás redireccionado a drupal.org), con lo que habría que modificar el fichero y sustituir la dirección del repositorio que necesitamos, bien Drupal Trademark siete o bien Drupal 8:
Para realizar esta modificación en tu composer.json puedes lanzar por consola la próxima instrucción y Composer se encargará de alterar el json:
Una vez atravesados los capítulos precedentes donde Drupal Trademark ha estado haciendo pequeños cameos, ahora toca ir relacionando todo lo visto previamente entre sí y darle un sentido estructurado al trabajo con Composer en el contexto de un proyecto Drupal. Repasaremos los aspectos más importantes.
4.1- Mecánica de trabajo
A continuación veremos ciertas ideas útiles para establecer rutinas básicas en nuestro trabajo diario con la terna Drupal — Drush — Composer.
Instalando Drupal Trademark a través de Composer
Existen muchas formas de instalar Drupal Trademark en una máquina (y cada vez más) mas ahora nos vamos a centrar en hacerlo mediante Composer, con la idea de fijar una mecánica básica de trabajo a modo de pequeño workflow que cualquier persona interesada en el topic pueda proseguir con comodidad.
Básicamente tienes 3 opciones para instalar Drupal a través de Composer. Asumiendo que ya tenemos Composer instalado en nuestra máquina y como ya señalamos en un apartado precedente, lanzamos por consola la instrucción:
Plan A)Usar drupal-composer como distribuidor (vendor) y drupal-project como recurso base, ya que trae algunos recursos incluidos que en el resto de casos se tienen que instalar aparte (como Drush, por servirnos de un ejemplo, o el caso del Complemento de Composer para manejar parches a la forma de dependencias):+
2.
Plan B)Usar el proyecto drupal-init creado por++
3.
Plan C)Usar drupal/drupal desde Packagist.org:+
Como puede verse en la próxima tabla comparativa extraida de la documentación de Drupal.org, cada opción tiene sus características:
Y aquí están las claves a la hora de decidirse: con el uso de drupal/drupal tendrás todo el contenido en el root del proyecto en lugar de producirlo dentro de una carpeta web (con lo que tendremos que hacer alguna redirección desde Apache para pedir nuestro Drupal Trademark), y a cambio Drush y Drupal Console tienen que ser dependencias incluidas aparte.
En mi opinión y en base al día a día, mi orden de preferencia en lo que se refiere a plantillas de composer.json no coincide con la secuencia de la tabla anterior: drupal-project me resulta la opción más optimada y la de hussainweb la última en orden de preferencia, deseo decir: A-C-B. La opción A es una plantilla Composer para proyectos Drupal creada en un inicio por el usuarioen2015 y contribuida a día de el día de hoy por muchas más personas de la comunidad Drupal Trademark.
Seguimiento del proyecto desde control de versiones
Inicialmente, dejar fuera de seguimiento de Git los recursos del core y los módulos contrib. Estos se gestionarán desde Composer, así que nuestro proyecto solo tendrá seguimiento por la parte de Git con respecto a la estructura inicial y aquello que ocurra en el directorio /contrib, donde irá todo nuestro trabajo en el día a día a partir de la triada Composer — Drush — Drupal Trademark.
En el caso del control de versiones (git), como en cualquier proyecto tenemos un fichero de seguimiento .git y un fichero de exclusiones llamado .gitignore, en el que se declaran todas las excepciones a continuar cuando se registren cambios en el proyecto. Bien.
Editando el archivo .gitignore del proyecto vamos a ver la exclusiones anotadas
¿Qué quiere decir esto?como existen una serie de elementos que ya están registrados en Composer como dependencias y serán elementos fijos o bien “anclados” del proyecto, ya no será necesario moverlos de un lado a otro a través de control de versiones. No se realizará seguimiento sobre ellos.
A partir de ahora, nuestra única preocupación será sostener el composer.json adecuadamente actualizado y subido al repositorio. En base a eso, cualquier usuario realizará una copia local en su máquina y tras lanzar
composer installo
composer updatetendrá el resto de dependencias ancladas del proyecto ya resueltas y también instaladas.
Se acabó subir cosas innecesarias al repositorio.
Aplicación de parches en el proyecto
Es bastante normal que mientras trabajamos desarrollando en un proyecto, descubramos que un módulo tiene un funcionamiento anómalo para el que hay que aplicar un parche específico a la espera que se integre (o bien no) a una versión siguiente. Es lo que generalmente solemos hacer utilizando git apply en en el directorio donde se encuentra el módulo justo tras traernos dicho fichero de texto con cambios que es en sí un parche software. Lo hacemos en local,
¿Así que el resto de nuestro equipo de trabajo debería hacerlo también? ¿y de manera tienda online presupuesto ? ¡No!controlamos la aplicación de parches manejándolos como dependencias y dándoles registro en el composer.json del proyecto.
Para ello contamos con la extensión de Composer “
composer-patches” que:
- O forma parte ya al seleccionar opción A) drupal-composer/drupal-project.
- O bien se instala en el resto de casos como una nueva dependencia mediante
Composer nos permite tratar los parches como dependencias a resolvery efectuar las implantaciones de esto. Para ello usaremos la estructura de la parte “
extra” del composer.json
Y en el próximo lanzamiento de composer update, se ejecutasen las instalaciones de los parches anotados en el composer.json.
“Composerizando” un proyecto Drupal
Puede acontecer que partiendo de un proyecto que fue instalado para pruebas en un ambiente local, se hayan realizado consecutivos cambios y desee establecerse este Drupal como base de trabajo.
Imagínemos que hemos instalado un Drupal simplemente a la manera clásica: descargando un comprimido, descomprimiendo y corriendo el instalador vía el navegador de internet. O.K.. Con el tiempo lo precisamos, lo hemos usado para proyectos y va bien, o bien sencillamente le hemos cogido cariño y deseamos hacerlo persistir un poco en esa versión y con esas configuraciones específicas. ¿Puede “Composerizarse” un proyecto Drupal Trademark a posteriori? la contestación es sí, con la herramienta composerize-drupal:+
Instalación:
Esta instrucción
composerize-drupalse encargará de edificar un composer.json coherente con el estado actual del proyecto a través de diferentes acciones que van desde cepillarse otros .json y .lock que existan por ahí dentro, crear un .json nuevo y darse un paseo por todo la estructura de directorios /modules/* , /themes/* con la idea de poblar todo el require con los datos de nuestra instalación Drupal Trademark, mergeando todas y cada una de las dependencias que se vaya encontrando por el camino.
4.2- Instalación de Drush vía Composer
Si es la primera vez que tomas contacto con Drush y has llegado aquí por que precisas instalarlo para un proyecto mas nunca has trabajado con él, lo primero que debes saber es que Drush fue considerado a lo largo de mucho tiempo como “la navaja suiza de Drupal” por ser una herramienta esencial para trabajar en proyectos de esta plataforma.
Con el tiempo su utilidad ha quedado algo diluida por la aparición de otras herramientas como exactamente el mismo Composer, la Drupal Console o el Drupal Trademark Code Generator. Aunque seguimos usándolo fielmente en el día a día para instrucciones que no tienen opción alternativa. Drush prosigue siendo la conjunción de “
Drupal + Shell”, el primer recurso para utilizar Drupal Trademark desde la línea de comandos.+ y en esta otra dirección puedes encontrar+.
En base a lo que venimos tratando, ya debemos intuir que instalar Drush en un proyecto Drupal a través de Composer debe ser bastante sencillo. De hecho solo sería preciso si hemos escogido el plan C de instalar Drupal mediante la opción drupal/drupal que no lo trae por defecto (En el resto de casos ya estaría en la carpetita /vendor).
Si hemos escogido drupal/drupal como opción de instalación estrategia de contenidos , lanzamos la instrucción para solucionar Drush como nueva dependencia:
Importante:para eludir posibles errores, es _muy_ recomendable registrar nuevas dependencias a través de
composer requirey no editando y/o manipulando directamente el composer.json a mano.
Y ya tendremos Drush instalado en nuestro proyecto. Ahora bien,
¿Cómo accedemos a él a través de sus comandos? ¿Cómo lo usaremos en nuestro proyecto?A partir de aquí se abren varias opciones. Vamos a ver las 2 tácticas más útiles.
Una parte esencial del trabajo con Drush es la de tenerlo accesible desde cualquier lugar en el que estemos trabajando y si se trata de una instalación local para un proyecto específico que requiera una versión concreta, entonces que Drush responda usando esa versión específica que está instalada como dependencia (como hemos visto en el párrafo precedente).
Táctica 1: Drush a través de alias de consola
La primera opción con la que podemos trabajar es la de crear un alias de consola a fin de que apunte siempre y en todo momento al ejecutable de Drush que deseemos usar en una instrucción.
Al fin y al cabo, cuando “instalamos” Drush estamos manejando unos binarios ejecutables, así que crear un alías de consola para utilizar en instrucciones sigue el esquema clásico de declarar el alías y dónde apuntará este para ejecutar algo. Por poner un ejemplo, si hemos llevado Drush a la ruta /usr/local/bin/ marcamos un alias que apunte a ella. Para ellos podemos utilizar el archivo .bashrc del sistema o uno más específico como el .bash_aliases (que tendríamos que crear). En cualquier caso, hay que introducir ese alias en el .bashrc editando con una de las próximas instrucciones:
En el caso de abrir con tu editor de texto phavorito el fichero (En un caso así el .bashrc), podrás ver diversos alias a lo largo del fichero:
¿Qué nos deja este enfoque?podemos tener tantas versiones de Drush como precisemos para cada uno de ellos de los proyectos que empleemos, siempre disponibles para usar. Para esto precisamos 3 pasos bien definidos:
- Descargar los recursos y situarlos en sus destinos.
- Crear los alias necesarios.
- Testear los alias.
Pensemos en instalar en nuestro sistema Drush en versiones seis, 7, 8 y 9.
1- Creamos directorios
ad-hocen el /home del usuario del sistema y descargamos los recursos precisos vía composer:
Y como curiosidad, irás viendo el
crescendoprogresivo de las dependencias a instalar junto a Drush:
2- Creamos alias de consola: para esto necesitamos acceder al archivo .bashrc en modo edición para añadir nuestras nuevas instrucciones. Este fichero está libre en el
/homede cada user de nuestro sistema.
3- Probamos si tanto los alias están apuntando bien a los recursos como si estos responden adecuadamente:
Y si todo ha ido bien, conseguiremos la información sobre versiones como retroalimentación en consola:
Táctica 2: Drush a través de Drush Launcher
Si en vez de establecer un Drush global de manera centralizada para todo el sistema (o varios) preferimos tener cada uno localizado como una dependencia específica en el
/vendorde cada uno de ellos de nuestros Drupales, entonces toma fuerza la opción de usar
Drush Launcheren nuestro proyecto:
+
Se considera una buena práctica -
de cara a eludir problemas de dependencias y versiones- el hecho de tener un Drush para cada proyecto de manera compartimentada. Para eso lo instalamos a través de Composer como una dependencia más del proyecto, que lo ubica en
vendor/bin/drushpara ser ejecutado a través de instrucciones, O.K.. Mas a partir de ahí, para acceder mediante comandos a las funciones de Drush necesitamos estar constantemente indicando que la senda es esa en cada comando.
Esto lo evitamos realizando una instalación de Drush Launcher de manera global para todo nuestro sistema. El Launcher se encargará de ir a buscar los ejecutables de Drush según el contexto de cada proyecto desde el que sea lanzado y responderá con el Drush existente en cada directorio
vendorque vaya encontrando.
Y ahora además de tener Drush instalado en nuestro proyecto, podremos convocarlo de manera sencilla.
Confirmamos el uso directo de Drush vía Launcher con
drush version:
4.3- Uso combinado de Drush y Composer con Drupal 8
Cuando ya tengamos Drush y Composer conviviendo en exactamente el mismo proyecto deberemos aprender a usar cada cual en su sentido específico, compartimentando funcionalidades que quizás antes estuvieran en el campo de responsabilidades del otro. Tomemos por poner un ejemplo el caso del comando de Drush “
en” (enable, para habilitar módulos ya descargados o bien si no lo están, descargarlos anteriormente y luego habilitarlos).
A partir de ahora, si lanzamos por ejemplo:
Obtendremos un mensaje clarísimo por pantalla: El proyecto ha sido ensamblado por Composer y solo será él quien se encargue de solucionar dependencias:
Así que aunque nos ofrezca la posibilidad de emplear
pm -forcecomo opción, lo mejor será que a partir de ahora empleemos
composer requirepara módulos.
Por último, vamos a realizar un ejercicio final combinando todas las acciones precedentes y todo el contexto que hemos ido recorriendo desde el comienzo del artículo. Esta secuencia está efectuada en un ambiente LAMP basado en Ubuntu o bien sistemas operativos Debian-based:
Esta sucesión de comandos creará una instalación de Drupal Trademark en tu carpetita destino plenamente funcional, con un perfil de administrador ya generado con las credenciales que devuelve el drush site-install al final de su ejecución (user-admin) y el modelo de datos de Drupal Trademark ya instalado en BBD. Por norma general, un Drupal ya funcional instalado y listo en tres comandos (o en menos si hemos escogido otra opción para Composer que no sea drupal/drupal).
Un Drupal marchando en tu máquina con tres instrucciones.
y si utilizas las opciones de instalación opciones alternativas a drupal/drupal, será suficiente con:
No está mal.
Como complemento, incluyo algunas referencias que estimo útil para ampliar más conocimiento sobre ciertos aspectos tratados en este artículo.
