Introduction à Composer – Partie 1

Cet article est le premier d’une série qui traitera l’outil de gestion de dépendances qu’est Composer.
Ceux d’entre vous qui ont assisté à l’API Hour #3 ne seront pas perdus puisque ces articles suivront à peu près la même trame que ma présentation, tout en étant plus complets. Mes slides sont d’ailleurs disponibles sur GitHub.

Le projet

Pour cet article et les prochains, nous allons considérer Propilex. C’est un pet project développé par WIlliam Durand principalement pour servir d’exemple pour l’intégration de Silex, Backbone.js et Propel. Même si nous n’allons nous intéresser qu’à la partie PHP de ce projet, n’hésitez pas à regarder le frontend, il y a aussi pas mal de choses intéressantes à voir !

Comme beaucoup de projets, Propilex a des dépendances :

Et maintenant ?

Même si j’ai omis une partie des dépendances pour des raisons de clarté, on voit déjà quelques problèmes se profiler à l’horizon.

Il y a pas mal de dépendances, et les questions suivantes se posent pour chacune d’elles :

Lesquelles sont vraiment nécessaires au projet ?
Parmi cette liste de dépendances, lesquelles sont vraiment nécessaire au bon fonctionnement du projet ? On me dit d’installer PHPUnit alors que je comptais déployer ce projet, est-ce vraiment nécessaire ?

Où est-ce que je suis censé les télécharger ?
Après une recherche sur Google, je tombe sur une page Google Code. Je recherche la section téléchargements mais en passant je vois un message indiquant que le projet à déménagé sur GitHub. Soit. Je suis le lien et arrive sur GitHub où  je télécharge une archive. Ou alors j’ai cloné le dépôt, je ne sais plus trop.

Comment les installer et les utiliser ?
Je me retrouve avec du code qui n’est pas le miens sur les bras.  Que dois-je en faire ? Je le laisse à la racine du projet ? Dans un dossier lib ? Un dossier vendor ?
Reste encore le problème de l’autoloading. Le projet fournit-il un autoloader ? Si non, il ne me reste plus qu’à mettre les mains dans le cambouis pour parvenir à autoloader ce dont j’ai besoin … et ne me parlez pas de require ou de l’include path !

Je comprends pas, ça marche pas !
Et en général, c’est à ce moment là que vous réalisez que toute votre installation est bancale à cause d’un problème de version. Que ce soit une version au dessus ou en dessous de celle du voisin, même l’écart le plus infime peut avoir des conséquences ravageuses.

Vous l’aurez compris, il nous faut un moyen d’automatiser tout cela.

Solutions

PEAR

Dans le monde PHP, PEAR est la solution qui vient naturellement. Ceci dit, je connais très peu de personnes qui utilisent PEAR pour installer une librairie, et encore moins pour en rechercher de nouvelles. Il faut avouer que niveau gestion de dépendances, Pear fait un travail proche du service minimum.

L’installation des librairies se fait au niveau du système. Vous avez deux projets sur la même machine qui dépendent de version différentes de la même librairie ? Dommage.
Un peu à la manière des dépôts Debian, PEAR possèdle un système de channels. Seulement, et contrairement à Debian, deux paquets identiques appartenant à des channels différents ne sont pas considérés comme égaux.
Il est impossible d’indiquer à PEAR les versions exactes dont on a besoin pour un projet. Il est d’ailleurs impossible de lui indiquer nos dépendances, il faut recourir à un README pour les lister et se reposer sur la personne installant le projet pour suivre nos instructions !

En clair, le problème de la localisation est dépendances et bel et bien résolu par PEAR, mais on voit bien que le reste n’est pas superbement géré. L’autoloading repose toujours sur l’include path, il n’y a pas de moyen d’installer automatiquement toutes nos dépendances et rien ne garantit que les versions que j’installe en production seront les mêmes que celles que j’ai testé en dev.

Submodules

Prenons cette fois le problème à l’envers. Quoi de mieux pour assurer que les versions des dépendances soient identiques pour tout le monde que de les « commiter » ? Bien sûr, versionner du code qui n’est pas le notre parait être une mauvaise idée, c’est pourquoi nous allons utiliser des submodules (dans le cadre de git, Mercurial a les « subrepos » et Subversion les « externals« ).

Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.

On laisse donc à git le soin de conserver les bonnes versions de nos submodules, mais il nous reste quand même à trouver vers quels dépôts ils doivent pointer et à gérer l’autoloading. On se rend néanmoins compte que le fait d’intégrer nos dépendances au niveau du projet nous permet de pouvoir utiliser plusieurs fois la même librairies dans des versions différentes sur la même machine.

Composer

Largement inspiré de NPM (node.js) et de Bundler (Ruby), Composer tente de réunir le meilleur de tous ces mondes.
En bref, Composer c’est :

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

Mais nous verrons tout cela dans un prochain article !