Introduction

Etant donnés les nouveaux besoins de SVP concernant la gestion des dépôts et des paquets, il est nécessaire de faire évoluer l’outil Smart-Paquets. Cependant, comme on le verra par la suite, l’outil est déjà codé de façon générique même si certaines options ne sont pas utilisées actuellement. L’adaptation devrait donc en être facilitée.

Pour rappel, le point d’entrée du script est la fonction PHP empaqueteur() dont le prototype est le suivant :

empaqueteur(
   $url,              // url du repository svn
   $dir_repo,      // répertoire relatif à ./ dans lequel est fait le checkout
   $dir_paq,       // répertoire où seront créés les paquets zip
   $src,              // fichier listant les paquets à archiver
   $dest,            // tableau résultat des paquets zip créés
   $xml,             // fichier xml contenant les informations de chaque contribution
   $nom_vcs,     // nom du gestionnaire de version utilisé pour le dépôt
   $mail_to,       // email du webmestre recevant les rapports
   $mail_from)   // email de l'émetteur

Gestion des dépôts multiples

La première évolution majeure apportée par SVP est la gestion de multiples dépôts “logiques” pouvant être ou pas installés sur un même dépôt physique (un repository SVN comme SPIP-Zone, par exemple). Ce qui matérialise un dépôt logique c’est sa liste de paquets archivés, soit actuellement sur SPIP-Zone, le fameux archivelist.txt.

Si l’on prend le cas de SPIP-Zone, on pourrait tirer avantage à scinder le dépôt physique en plusieurs dépôts logiques SVP comme :

• un dépôt pour le grenier, qui ne contiendrait que les archives souhaitées de l’arborescence root/_grenier_/. Le fichier des paquets pourrait se nommer archivelist_grenier.txt
• un dépôt pour les plugins et squelettes décrit par un fichier archivelist_plugin.txt et allant chercher les sources dans les arborescences root/_plugins_/, root/_squelettes_/ et root/_themes_/
• un dépôt pour les tags décrit par un fichier archivelist_tag.txt et des sources dans root/tags/
• un dépôt pour les autres contributions décrit par un fichier archivelist_contrib.txt

L’intérêt d’un tel système, outre le fait d’amener une certaine clarté et un critère de tri dans le futur site plugins.spip.net motorisé par SVP, est de pouvoir gérer séparément les générations d’archives. Si le dépôt des plugins a tout intérêt à être généré chaque heure, ce n’est pas le cas des trois autres. On pourrait donc optimiser la charge du serveur.

Pour implémenter cette évolution il me semble que l’on peut opérer les modifications suivantes dans le script empaqueteur() :

• l’argument $url devient un tableau d’urls pour permettre le check-out d’une liste d’arborescences comme pour le dépôts des plugins : root/_plugins_/, root/_squelettes_/ et root/_themes_/
• l’argument $dir_repo permet de définir le répertoire de check-out de chaque dépôt logique, par exemple, grenier/, plugins/, tags/, contrib/
• l’argument $dir_paq permet déjà de caractériser le répertoire de création des paquets qui pourrait devenir : paquets_grenier/ ou paquets/grenier/
• idem pour l’argument $src qui devient archivelist_plugin.txt
• par contre, pour l’argument $dest il faut conserver la valeur actuelle, soit « archives » et générer un fichier xml des paquets nommé archives_plugin.xml en trouvant le moyen de connaitre l’alias du dépôt (cf le paragraphe suivant).

La gestion des check-out n’est peut-être pas optimale dans ce cas et demanderais éventuellement à déplacer certaines contributions en particulier pour le dépôt « contrib ».

Informations sur un dépôt

SVP a besoin de connaître quelques informations sur le dépôt logique comme l’url des sources, celle des paquets, le type de gestionnaire de versions, son titre, sa description... Toutes ces informations ne sont pas indispensables à l’exception de l’url des paquets que l’on peut déduire du fichier xml des paquets et l’url des sources si l’on veut effectuer des mises à jour via le gestionnaire de version.

Même si tout n’est pas figé actuellement il parait nécessaire aujourd’hui de se doter d’un moyen de fournir à SVP des informations sur chaque dépôt.

La solution qui parait la plus simple est d’ajouter dans le fichier listant les paquets archivés du dépôt - archivelist.txt actuellement - un bloc d’information sur le dépôt avec une syntaxe à définir. On peut imaginer quelque chose comme suit :

Sinon, pourquoi ne pas passer ce fichier en yaml pour améliorer sa lisibilité et éviter de construire une syntaxe absconse dans le .txt ?

Récupération des logos

Pour l’instant, SVP ne sait pas récupérer les logos autrement qu’en construisant une url du type export/HEAD/nomlogo.png. A priori cette écriture n’est pas toujours possible suivant les protections du repository (à confirmer). Il serait donc préférable :

• soit d’exporter les logos dans un répertoire accessible par une url, comme les paquets ; mais cela nécessite d’ouvrir le fichier plugin.xml pour connaitre le logo
• soit d’utiliser le répertoire de check-out $dir_repo pour définir l’adresse du logo dans SVP (mais il faut que ce répertoire soit également accessible).

Il est à noter que la recherche du logo serait grandement facilitée si celui-ci avait un nom standard du type prefixe_logo.xxx à la racine du plugin.

Utilisation de différents gestionnaires de version

Aujourd’hui Smart-Paquets est codé pour fonctionner avec un repository SVN. L’idée est d’étendre les fonctions de l’outil à d’autres gestionnaires comme Git et aussi à un dépôt non géré.

Smart-Paquets prévoit déjà cette possibilité au travers d’une fonction d’exec spécifique à chaque gestionnaire. Aujourd’hui seul la fonction empaqueteur_exec_svn() est codée. Pour utiliser Git il faudrait d’une part créer la fonction empaqueteur_exec_git() mais aussi une couche d’abstraction des commandes pour que les commandes checkout ou info soient traduites en Git.