Dynamic-Mess.com


"The world is a dynamic mess of jiggling things..."

Installer et utiliser composer sous Linux

Article posté le 03-11-2014 dans la catégorie Linux

Composer PHP

Plus besoin de présenter composer : il s'agit du gestionnaire de paquet de PHP le plus utilisé. Le but de ce petit tutoriel est de vous expliquer comment l'installer sous Linux, ainsi que son utilisation basique.

1- Installation de composer

Il y a trois façons de procéder. Deux d'entre-elles nécessitent PHP.

La première: ouvrez la console, et copions composer.phar, le fichier de composer :

php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

La deuxième, toujours dans la console:

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

Troisième méthode: télécharger l'installer sur le site de composer. Ensuite positionnez vous, avec la console, sur le répertoire où se trouve l'installer, et faites :

php installer

A présent que vous avez installé composer, copions-le à présent dans /user/local/bin afin de pouvoir y accéder depuis tout le système :

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

Pour vérifier que tout c'est bien passé, ouvrez une nouvelle console , et tapez :

composer --version

Vous aurez alors la version de votre installation de composer!

Note : il se peut que vous ayez aussi besoin de Git pour certains bundles que vous souhaiterez installer plus tard via composer. L'installation de Git est simplissime :

apt-get install git

 

2- Mettre à jour composer

La mise à jour de composer s'effectue simplement, via cette commande :

composer self-update

 

3- Gestion du projet: création et mise à jour

Quand vous téléchargez un projet, vous ne téléchargez en général, pour des raisons de performances, que son squelette: il s'agit des fichiers coeurs de ce projet. Il manque tout ce qui est encombrant: les dépendances.

Un projet utilisant composer dispose d'un fichier listant les dépendances du projet: composer.json. Pour les télécharger et ainsi créer ce projet, rien de plus simple:

 composer install

Mais mais mais... Il est recommandé, quand vous créez un projet, de créer aussi un fichier composer.lock. Celui-ci aura pour objectif de gérer les dependances ainsi que leur version de référence, une sorte de guide plus précis que le composer.json. Alors que le fichier .json ne contient lui que leur nom ou alors une version peu précise de celle requise pour votre projet, le .lock doit contenir la version exacte, leur checksum, les dépendances des dépendances.

Pour bien comprendre, voici ce que fait la commande install:

Exemple d'application: supprimez votre dossier vendor, faire un composer install à nouveau: il va télécharger tout ce qui est précisé dans le .lock.

Je viens de parler de la commande update. Vous devinez qu'il s'agit de la mise à jour du projet. Ce n'est pas aussi simple. Voici ce qu'elle fait:

A présent, vous comprenez qu'un update ne doit pas être fait à la légère! Ou alors, faites le que pour une seule dépendance bien précise! Le fichier .lock étant aussi géré dans votre gestionnaire de version (SVN, Git...), cela signifie que si vous faites un update sans vous concertez, vous risquez de vous retrouvez tous avec une version de dépendance non validée par l'équipe. Le fichier .lock sert donc de base sur les versions précises requises! Cela signifie ainsi que si vous validez de passer à une nouvelle version d'une dépendance, vous aurez juste à éditer le fichier .lock manuellement, et le mettre à jour chez toute l'équipe de développement. C'est aussi le rôle de ce fichier: quand vous ouvrez un projet après avoir fait un composer install, ouvrez le .lock : vous aurez ainsi  sous les yeux la version précise de chaque dépendance installée. Néanmoins, sachez une chose: le composer.lock n'est pas toujours versionné, cela dépend des habitudes des équipes. Sachez également qu'un conflit dans composer.lock n'est pas grave, annulez l'une ou l'autres des modifications, de manière cohérente: en effet, le fichier sera dans tous les cas regénéré dans le cas d'un composer install...

Il y a parfois des petites exceptions. Par exemple si vous souhaitez créer un projet sous Zend Framework 2. Vous allez donc télécharger son squelette, le Zend Framework 2 Skeleton. A l'intérieur, il y a un fichier .json au complet (framework + dépendances), mais ce n'est pas le cas du .lock. Cela permet ainsi de démarrer avec la toute dernière version du framework mais une version précise des dépendances.

Maintenant un conseil: quand vous souhaitez installer une nouvelle dépendance, faites donc un composer install, comme ça il ne touchera pas au reste. Si vous faites un update, pratique trop répendue, il va en plus mettre à jour les autres dépendances + le fichier .lock. Voici en effet les cas où votre .lock est modifié:

Un dernière chose: certains packages ne doivent être installés que dans des environnements de développement (donc pas en production). C'est le cas de PHP Unit par exemple. Pour faire cela, vous avez juste à passer un paramètre à votre commande :  --dev. Exemple:

composer require vendor/module --dev

Néanmoins, si vous faites un simple composer install, ils seront quand même installés (l'environnement de prod est par défaut maintenant). Il faut donc préciser si ce n'est pas le cas, par exemple pour un environnement de dev: 

composer install --no-dev

 Plus d'infos ici.

4- Quelques commandes utiles 

Mettre à jour qu'une seule dépendance (possible de préciser la version)

composer update foo/bar

Cette commande peut aussi être utilsiée dans une variante afin de mettre à jour votre .lock à partir de votre .json, notamment quand vous avez ce message:

Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them.

Ceci peut être provoqué par une modification volontaire, ou même un espace en trop, bref n'importe quoi qui altererait le checksum de votre .json. Pour régler le problème:

composer update --lock

 

Ajouter une dépendance sans modifier le fichier soit-même

 composer require "vendor/module:1.0.0"

Note: si vous ne précisez pas la version: composer prendra automatiquement la dernière version stable

Note 2: vous pouvez donc préciser ce que vous voulez comme version mais également jusqu'ou vous voulez aller, en utilisant les caractères ~ et ^. Exemple:

~1.2 signifie que vous voulez une version >=1.2 et < 2.0.0

~1.2.0 signifie que vous voulez une version >=1.2 et < 1.3.0

Toutefois l'utilisation du caractère ^ est recommandée: ^1.2.3 signifie une version >=1.2. et < 2.0

Voici quelques exemples :

.json    "vendorname/mymodule": "~1.0", // version demandée dans le composer.json
.lock     "version": "1.20", // version installée, la dernière disponible

Autre exemple dans un autre projet avec le meme composant:

json : "vendorname/mymodule": "^1.14" // version demandée dans le composer.json
lock:   "version": "1.20", // version installée, la dernière disponible

Autre exemple en json: "vendorname/my-bundle": "^1.27", accepte toutes les versions 1.x

Ajouter toutes les dépendances d'un vendor

composer require 'react/react=*'

Retirer un module

composer remove vendor/module-name

Créer un projet à partir d'un dépôt

composer create-project doctrine/orm path 2.2.0

 

Optimiser l'autoload avant le passage en production de votre projet

composer dump-autoload --optimize

Exécuter composer dans un autre répertoire

Exemple: 

composer -d=/var/www/test/current install --no-dev

Vider le cache

composer clearcache

ou juste celui de quelques packages en particuloer:

composer clearcache packagename1 packagename2 ...

Un petit bilan des commandes

Un internaute bien intentionné a créé une page qui récapitule bien la plupart des commandes de composer.

5-Erreurs lors de l'installation

Note : Parmi les erreurs fréquemement rencontrées, voici les deux principales et leur solution :

Plus globalement, après l'installation de composer, vous pouvez effectuer un diagnostic de votre installation avec cette commande :

composer diagnose

6- Fichier où sont stockées d'éventuels identifiants composer pour des dépôts privés

~/.composer/auth.json

Exemple de contenu du fichier:

{    "http-basic": {
        "repo.mondepot.com": {
            "username": "fjlkre5j56fk4r8e2j8k2l8f3j4lkerfj",
            "password": "g5d6h75yd2h8j4r2vgh72hy4f4"
        }
    }
}

7- Créer une dépendance installable via composer

Une fois que votre repository git dédié à votre module est créé, vous pouvez travailler directement en l'intégrant dans un "vrai projet" pour faire vos tests. Exemple d'un module my-bundle, que vous développez. Vous voulez travailler avec la branche 2.0-workging-branch mais dans le cadre d'un projet existant, pour tester son intégration. Voici ce que vous devez taper dans le dit projet:

composer require vendorname/my-bundle:dev-2.0-workging-branch  --prefer-source

En allant dans vendor/vendorname, vous trouverez votre bundle avec son dépôt git, vous permettant ainsi de travailler directement dedans et évitez les aller retours.


Cet article vous a plu? Découvrez d'autres articles


Tweet
comments powered by Disqus