Introduction à Composer – Partie 2

Dans mon précédent article, j’exposais les problèmes que la gestion de dépendances pouvait apporter et je j’introduisais rapidement Composer comme une solution. Cet article a pour but de développer la réponse apportée à ce problème par cet outil.

Composer, c’est quoi ?

Pour faire court : Composer est un outil (écrit en PHP) permettant de lister les dépendances de votre projet et de les installer. Si on détaille un peu plus, Composer c’est :

• une gestion des dépendances par projet ;
• une installation des dépendances automatisée ;
• une résolution efficace des dépendances au moyen d’un solveur SAT ;
• et quelques bonus.

Il est important de remarquer que même si Composer gère des paquets, il n’en demeure pas moins un gestionnaire de dépendances et non pas un gestionnaire de paquets dans le sens où l’est aptitude ou yum. Composer gère les dépendances par projet et n’installera rien de manière globale au système.

Comment ça marche ?

Installation de Composer

Commençons par le commencement : l’installation.
Et voilà, vous vous retrouvez avec un joli fichier nommé « composer.phar » à la racine de votre projet. Vous pouvez vérifier que tout fonctionne en l’exécutant :

Ce qui devrait afficher la liste des commandes exposées par Composer. Déclaration des dépendances Maintenant que Composer est installé, nous allons déclarer les dépendances de notre projet. Pour cela, Composer utiliser le fichier « composer.json » situé à la racine du projet. Comme son nom l’indique, c’est un fichier « texte plat » dont le contenu est formaté en JSON.

Dans sa forme la plus épurée, le composer.json ne contient que la liste des dépendances sous la forme d’une liste associative package -> version. Voici un composer.json que l’on pourrait utiliser dans le cadre de Propilex, le projet qui nous a servit d’exemple dans l’article précédent :

Vous remarquerez que les noms des packages respectent tous le même format : vendor/nom-du-package. Mais au fait, un package, c’est quoi ? Un package, c’est tout simplement un dépôt ou une archive comprenant un composer.json à sa racine.

Installation des dépendances

Nos dépendances étant désormais formellement décrites, Composer peut les installer :
Une fois l’exécution de la commande terminée, on se retrouve avec un dossier « vendor » contenant nos dépendances :

Un autre fichier a été créé : le fichier composer.lock.

C’est un fichier très important car contrairement au composer.json qui décrit des contraintes générales sur les dépendances, celui-ci indique les versions exactes qui ont été installées. C’est ce fichier qui garantit que les autres développeurs travaillant sur ce projet installeront exactement les même dépendances que vous et dans les mêmes versions.

N.B : vous prendrez donc soin de versionner les fichiers composer.json et composer.lock alors que vous ignorerez impitoyablement le dossier vendor (au moyen d’un .gitignore par exemple).
Le fichier composer.lock étant généré automatiquement, il est très fortement déconseillé de l’éditer manuellement (à moins de vraiment savoir ce que vous faites … et encore).

Premier bonus : l’autoloading

Les plus observateurs auront remarqué que Composer ne se contente pas d’installer vos dépendances, mais qu’il génère aussi un autoloader capable de les charger. Cet autoloader est contenu dans le fichier vendor/autoload.php. Il suffit donc de l’inclure dans votre application pour pouvoir immédiatement utiliser vos dépendances. Sympa n’est-ce pas ?
En général, un projet ne se limite pas à une liste de dépendances, il est aussi composé de code (Captain Obvious to the rescue!).
Composer est aussi capable de gérer l’autoloading du code du projet. Pour cela, on ajoute une directive dans le composer.json permettant lui permettant de savoir comment charger notre code.

Dans le cadre de Propilex, le code est situé dans le répertoire « src/ » et respecte le standard PSR-0. On augmente donc le composer.json pour refléter ces besoins :

Pour re-générer l’autoloader, on exécute la commande suivante :

Pro-tip : utilisez l’option --optimize (ou -o) pour générer un autoloader plus performant (utile en production).

Gestion des dépendances

Durant le cycle de vie, il est commun de vouloir installer, mettre à jour ou supprimer des dépendances. Voyons comment réaliser tout cela.

Installation

Premier cas : vous venez de récupérer une copie du projet et aucune dépendance n’est encore installée. Vous êtes en fait dans le cas précédemment traité et n’avez qu’à utiliser la commande suivante :
Composer installera les dépendances du projet en se basant uniquement sur le contenu du fichier composer.lock s’il existe, ou du fichier composer.json sinon.

Second cas : les dépendances sont déjà installées mais vous avez besoin d’en ajouter une nouvelle. La commande require sera cette fois celle qu’il faudra utiliser :

Composer se chargera de mettre à jour à la fois le composer.json et le composer.lock, la dépendance sera installée dans le dossier vendor et l’autoload sera re-generé.

Pro-tip : en production, utilisez l’option --optimize pour bénéficier d’un autoloading plus rapide et l’option --prefer-dist qui aura pour effet d’indiquer à Composer que l’on voudrait télécharger une archive contenant uniquement la version désirée au lieu de cloner tout le dépôt.

Mise à jour

Rien de plus simple, comme en témoigne la commande suivante :
Composer mettra à jour le package « vendor/package » en se basant sur les règles fixées dans le composer.json et mettra à jour le composer.lock. Si vous souhaitez mettre à jour toutes vos dépendances d’un coup, il suffit de ne pas spécifier de nom de paquet à la commande update. N.B : si le fichier composer.lock n’existe pas, install et update sont équivalents. Sinon, le premier se base sur le contenu du composer.lock pour installer les dépendances alors que l’autre utilise composer.json.

Suppression

Ce cas est en quelque sorte le plus « fourbe » dans le sens où Composer ne dispose pas de commande « uninstall« . La marche à suivre pour désinstaller un paquet est cependant très simple :

• supprimez l’entrée correspondant au paquet dans le composer.json ;
• et faites un php composer.phar update "vendor/package" sur ce même paquet.

Composer est assez intelligent pour supprimer les dépendances inutiles lors d’un update. Forcer un update sur un paquet modifié n’aura donc aucun autre impact que de mettre à jour le composer.lock et de supprimer la dépendance du dossier vendor.

Les dépôts de paquets

Il reste encore un point assez magique dans tout ce beau processus : où Composer va-t-il chercher nos packages ? En effet, on ne lui donne comme information qu’un nom !

L’explication est simple : un peu comme le ferait Debian, il utilise des dépôts / sources de paquets. La seule différence étant que dans le cas de Composer, les « dépôts » se content de stocker des méta-données sur les paquets qu’ils connaissent (dont les informations permettant de le télécharger) et non pas le code dans sa totalité.

Packagist est le dépôt principal utilisé par la communauté. La quasi-totalité – pour ne pas dire la totalité – des librairies destinées à être publiques sont enregistrées sur ce site, que Composer utilise par défaut lorsqu’il recherche un paquet.
Il n’est bien entendu pas obligatoire qu’un paquet figure sur Packagist pour pouvoir être installé, mais ça facilite quand même bien les choses.

Pour le cas des paquets/librairies qui ne sont pas publiques, il est possible d’installer sur un serveur une instance de Satis qui fera office d’un Packagist-like privé. Outil très utile, notamment dans le cadre de librairies internes à une entreprise.

Comme le montre l’exemple ci-dessous, la configuration nécessaire pour ajouter une source de données est très simple :

Grâce à cette entrée supplémentaire dans le composer.json, Composer sait qu’il doit désormais utiliser une source de données supplémentaire.

Pour plus d’informations concernant l’utilisation de Satis, référez vous à la section de la documentation le concernant.

What now?

Dans un prochain article, nous aborderons un peu plus en profondeur l’utilisation de Composer et découvrirons quelques fonctionnalités plutôt intéressantes qu’il nous offre.

See ya!