logo-composer-transparent

Composer es una herramienta para la gestión de dependencias en PHP. Nos permite definir, de una manera muy simple, las librerías (paquetes a partir de ahora) que necesita nuestra aplicación y las descarga por nosotros. Sin duda, ha sido una de las mejores noticias de los últimos años en el mundo PHP, ya que ha cambiado radicalmente la forma en la que construimos los proyectos. Es posible encontrar paquetes de calidad para casi cualquier funcionalidad en Packagist.

En este tutorial mostraremos como instalarlo y empezar a utilizarlo.

Instalación

Windows

La forma más sencilla de instalar Composer en Windows es descargar y ejecutar su instalador. También se encargará de actualizar la variable %PATH% para que pueda ser llamado desde cualquier directorio en línea de comandos.

*nix

En sistemas Unix como Linux o Mac OS, la instalación se realiza descargando el instalador con cURL, que no es más que un script PHP que debe ejecutarse. Éste se asegurará que Composer puede ser usado en el sistema. Después, descargará automáticamente el fichero composer.phar, que es el ejecutable de Composer. La instrucción para realizar la instalación sería la siguiente:

$ curl -sS https://getcomposer.org/installer | php

Para instalar Composer de forma global en el sistema y poder usarlo como cualquier otro comando, es tan sencillo como copiar el archivo composer.phar en alguno de los directorios incluidos en la variable de entorno PATH, por ejemplo en /usr/local/bin:

$ mv composer.phar /usr/local/bin/composer

Como funciona

Composer es un gestor de dependencias por proyecto, por lo que los paquetes necesarios para nuestra aplicación no se instalarán globalmente como ocurre con PEAR, sino en un directorio especial llamado vendor. Después, simplemente añadiendo un require_once del archivo de autoload que genera Composer tendremos acceso a todas nuestras dependencias.

Las dependencias se definen en un archivo llamado composer.json. Un ejemplo simple sería el siguiente:

    "require": {
        "fabpot/goutte": "v1.0.5"
    }

En el ejemplo anterior definimos una única dependencia, el paquete “fabpot/goutte”, que sirve para hacer screen scrapping y web crawling en PHP.

Cuando ejecutamos “composer install”, Composer comprueba las dependencias que hemos definido y descarga los paquetes necesarios para satisfacerlas:

$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
  - Installing symfony/event-dispatcher (v2.4.2)
    Downloading: 100%
  - Installing guzzle/common (v3.8.1)
    Downloading: 100%
  ...
  - Installing symfony/browser-kit (v2.4.2)
    Downloading: 100%
  - Installing fabpot/goutte (v1.0.5)
    Downloading: 100%

symfony/event-dispatcher suggests installing symfony/dependency-injection ()
symfony/event-dispatcher suggests installing symfony/http-kernel ()
Writing lock file
Generating autoload files

Como puedes comprobar, Composer no solo ha descargado “fabpot/goutte”, también algunos paquetes adicionales. Esto se debe a que el paquete “fabpot/goutte” define a su vez otras dependencias – se pueden comprobar en su archivo composer.json -, pero no nos tenemos que preocupar de esto, Composer se encarga automáticamente de calcular el grafo de dependencias. Este es un proceso bastante costoso si el número de dependencias crece, por lo que Composer intenta minimizar el problema creando el archivo composer.lock, que contiene las versiones exactas de todos los paquetes a instalar. Así, la próxima vez que ejecutemos “composer install”, Composer simplemente leerá el archivo composer.lock y descargará los paquetes. Si modificamos el archivo composer.json, necesitamos ejecutar “composer update” para que el archivo composer.lock se calcule de nuevo.

“composer update” es el nuevo “compilando…” :)

Una vez que los paquetes se han descargado, Composer genera un archivo php que debemos incluir en el proyecto para poder utilizar las dependencias. Éste archivo registra un autoloader PSR-0/PSR-4, lo que facilita hacer uso de las dependencias:

<?php

require_once __DIR__.'/vendor/autoload.php';

use Goutte\Client;

$client = new Client();
$crawler = $client->request('GET', 'http://www.servergrove.com');
$title = $crawler->filter('head > title')->text();
echo $title;

En el ejemplo anterior, incluímos el archivo autogenerado autoload.php, y a continuación creamos un objeto de la clase Goutte\Client, que forma parte del paquete “fabpot/goutte”. Por último, utilizamos el objeto para extraer el contenido de la etiqueta title de la página web de ServerGrove.

El comando composer

Ya hemos hablado de los comandos “install” y “update”, pero Composer dispone de algunos comandos adicionales. “composer list” muestra una lista de todos los comandos disponibles:

$ composer list
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/

Available commands:
  about            Short information about Composer
  archive          Create an archive of this composer package
  config           Set config options
  create-project   Create new project from a package into given directory.
  depends          Shows which packages depend on the given package
  diagnose         Diagnoses the system to identify common errors.
  dump-autoload    Dumps the autoloader
  dumpautoload     Dumps the autoloader
  global           Allows running commands in the global composer dir ($COMPOSER_HOME).
  help             Displays help for a command
  init             Creates a basic composer.json file in current directory.
  install          Installs the project dependencies from the composer.lock file if present, or falls back on the composer.json.
  licenses         Show information about licenses of dependencies
  list             Lists commands
  require          Adds required packages to your composer.json and installs them
  run-script       Run the scripts defined in composer.json.
  search           Search for packages
  self-update      Updates composer.phar to the latest version.
  selfupdate       Updates composer.phar to the latest version.
  show             Show information about packages
  status           Show a list of locally modified packages
  update           Updates your dependencies to the latest version according to composer.json, and updates the composer.lock file.
  validate         Validates a composer.json

Algunos comandos interesantes:

  • init: Crea un archivo composer.json de forma interactiva.
  • validate: Comprueba si el archivo composer.json es válido.
  • selfupdate: Actualiza Composer a la última versión disponible. Si la versión de Composer es demasiado antigua – 30 días o más -, se muestra un mensaje de alerta cuando se ejecuta cualquier comando.
  • search: Busca paquetes en Packagist – por ejemplo, “composer search yaml” -.
  • show: Muestra información sobre los paquetes. Por ejemplo, “composer show –installed” muestra un listado de los paquetes instalados.
  • create-project: Crea un nuevo proyecto a partir de un paquete. Es bastante útil para frameworks – por ejemplo, para crear un nuevo proyecto Symfony2: “php composer.phar create-project symfony/framework-standard-edition path/ 2.4.2″.

Versiones de los paquetes

Hay varias formas de definir qué versión o versiones aceptamos en nuestro proyecto:

  • Versión exacta: “1.4.2″, “v1.4.2″.
  • Rangos: “>=1.0,<2.0", ">=1.0,<1.1 | >=1.2″.
  • Comodines: “1.0.*”, “1.*”.
  • Next Significant Release: “~1.2″ es equivalente a “>=1.2,<2.0".

Estabilidad

Cada una de las versiones de los paquetes dispone de un stability flag, que indica si la versión es “final” o si en cambio se trata de una versión previa (p.ej. beta). Por defecto, solo se tienen en cuenta las versiones finales, por lo que si necesitamos alguna versión no stable, debemos cambiar el parámetro minimum-stability. Los valores disponibles son “dev”, “alpha”, “beta”, “RC” y “stable”. También es posible definir el minimum stability por dependencia, añadiendo “@flag” a la versión del paquete – por ejemplo “”fabpot/goutte”: “1.0.*@dev””.

El directorio “vendor”

Composer crea automáticamente el directorio vendor, que debemos ignorar en el sistema de control de versiones (VCS) – por ejemplo, añadiéndolo al .gitignore en GIT-. Es recomendable incluir el archivo composer.lock en el VCS para que todo el equipo de desarrollo utilice exactamente las mismas versiones de los paquetes. Se acabó la excusa de “funciona en mi ordenador…”!

Más información

Éste artículo es solamente una introducción a Composer y como empezar a utilizarlo en nuestros proyectos para gestionar sus dependencias. Si deseas profundizar más, Composer dispone de una excelente documentación, tanto para creadores de paquetes como para los consumidores.

This post is also available in: Inglés