composer.lock

Dans la foulée des autres interventions sur composer, voici un bref résumé du rôle du fichier composer.lock.

composer cherche les versions optimales des dépendances du projet de base pour les installer ou les mettre à jour.

Il s’appuie sur le contenu du fichier composer.json, en particulier sur le contenu de la clé require ainsi que des versions de PHP et des extensions PHP de la machine où le caclul est effectué.

C’est un calcul couteux, autrement dit, lent, et qui implique des échanges de données avec des référentiels accessibles sur Internet (dont packagist.org).

SPIP à besoin d’un second dépôts composer : spip/composer

Mais composer peut aussi utiliser d’autres formes de dépôts qui seront utiles ou pas selon les besoins de chacun.

Le résultat de ce calcul peut être, soit fourni avec le fichier composer.json (donc, versionné avec dans le dépôt git) dans le fichier composer.lock, soit recalculé si le fichier est absent.

La commande composer update va recalculer les versions optimales, en s’appuyant sur le contenu des 2 fichiers composer.json et composer.lock. En cas de nouveauté à mettre à jour, il pourra éventuellement mettre à jour le fichier composer.lock

La commande composer install va prendre en compte le fichier composer.lock s’il est présent ou passer à une phase « update » si ce fichier est absent.

Les commandes composer require et composer remove vont mettre à jour les 2 fichiers (json et lock) si cela s’avère nécessaire (c’est le but, mais si la commande ne procède à aucun changement, il n’y aura pas de mise à jour des fichiers …)

S’il y a un décalage entre les 2 fichiers, composer pourra le signaler selon les circonstances.

L’article Basic Usage evoque le cas du versionning du fichier composer.lock : Basic usage - Composer (puis Libraries - Composer)

Ce qu’il faut retenir, c’est qu’il n’est pas nécessaire pour une library (qui n’a vocation qu’à être une dépendance d’un autre package) de versionner ce fichier.

Mais la question se pose pour un « project » : si c’est votre SPIP, oui, il faut le versionner dans un dépôt dédié à votre SPIP.

Si c’est une distribution logicielle, comme spip/spip, par exemple, ce n’est pas nécessaire, en particulier avec flex, car ce dernier permet de mieux distinguer le cas où quelqu’un « développe SPIP » du cas où queqlu’un·e « développe SON site ».

Toutefois, la communauté SPIP propose des distributions zippées de SPIP (ecrire+prive+plugins-dist+squelettes-dist+config par défaut) pour les gens qui n’utilisent pas composer. On pourrait donc décider de conserver un composer.lock pour faciliter la création de ces distributions officielles. Néanmoins, cela impliquerait pour les personnes qui développent SPIP de penser à suivre en git l’évolution de ce composer.lock à chaque composer update. C’est donc une question à trancher : préfère-t-on faciliter le travail de release (et dans ce cas on versionne) ou celui de développement (et dans ce cas on ne versionne pas) ? Pour sortir de ce dilemme, les outils de release de gitlab pourraient aider.

2 « J'aime »