Re: Plugin Composer (getpackagist) - paquet.xml

Le 12/02/2016 11:43, Matthieu Marcillaud a écrit :
> La difficulté va être de faire comprendre ça à SPIP car paquet.xml
> n'a pas une déclaration extensible. Il faudrait soit rendre possible
> des ajouts à la DTD (mais je ne pense pas que cela soit réalisable), et
> des traitements associés à l'ajout, soit modifier directement le Core
> pour ajouter ta nouvelle déclaration dedans.

Pour ce point, je ne crois pas du tout qu'il faille changer la DTD.

Il s'agit très précisément de dépendance externes, donc de la balise 
<lib> déjà existante.

Elle sait déjà gérer un paquet à télécharger et dézipper. Mais que ce cas.

Je pense donc que la solution pour ce point (et comme tu le dis bien, 
qui ne résout que les cas *simples* d'utilisation de Composer avec 
require) c'est que le *traitement* des <lib> ait un pipeline.

Et qu'on puisse possiblement "typer" les <lib>, genre
lien="http://url/du/zip"
lien="github:id/projet"
lien="packagist:fournisseur/projet"
voire même
lien="git:http://url/machin.git"
lien="svn://depot/svn"

Bref n'importe quoi du moment qu'on a un plugin qui sait gérer suivant 
telle ou telle info donnée.

Pour ça, il suffit que le noyau de SPIP
1) récupère des infos, le lien, le "scheme" si c'est un format standard 
(svn:// par ex), le type si ya un préfixe ("packagist:"), etc, les 
formats étant à discuter, peu importe
2) garde ça dans un tableau
3) continue de gérer quand c'est un ZIP classique
4) ne fasse rien s'il sait pas gérer, mais sans planter
5) appelle un pipeline avec le tableau d'infos

Et les autres plugins feront mieux s'ils savent y faire.

En l'occurrence le plugin Composer intercepterait toutes les libs avec 
lien="packagist:truc/machin" et il téléchargerait et installerait là où 
on le décide.

Donc vu qu'on est sur cette liste pour parler du noyau, c'est la seule 
modif du noyau qui me semble utile, ajouter ce pipeline.

-- 
RastaPopoulos