Re: Plugin Composer (getpackagist) - paquet.xml

Le 12/02/2016 10:39, [email protected] a écrit :

> Oui à mon sens vouloir un paquet composer c'est demander une lib au
> sens de paquet.xml d'où l'idée de rendre transparent cet appel.
>
> La mécanique sous jacente resterait dans la même idée de Marcimat en
> jouant sur pipeline et cie.
> Il y aurait une traduction paquet.xml -> composer.json ainsi on
> exploite au mieux les mécaniques SPIP

J'ai peur que ce soit réducteur (ou insuffisant) de simplement indiquer 
une ligne dans paquet.xml pour de nombreux cas. Mais pour la plupart
qui ajoutent juste un "require" ça peut possiblement le faire.

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.

Accessoirement j'ai mis le composer.json dans config/ et non à la 
racine, car parfois il n'est pas possible à apache d'écrire à la racine 
du site directement. Mais c'est peut être une mauvaise idée de ma part.


> Avec composer on n'est pas obligé de mettre le tout dans vendor/ , on
> peut cibler ailleurs.
> Il y a des subtilités mais il y a quand même possibilité de sortir du
> cas d'usage proposé par défaut.

Oui. Cependant je vais expliquer mon choix de conserver "vendor/" 
actuellement, même si je suis partagé également.

À mon sens les fichiers de vendor/ ne devraient pas être accessibles 
depuis le web, ce qui du coup (pour moi) empêche l'usage de lib/ pour 
cela), et suggérerais de le mettre dans tmp/ ou dans le mal nommé 
config/ (si on le considère comme "permanent inaccessible").

Du coup j'ai laissé vendor/ car c'est ce qui est le plus utilisé et 
connu ; par contre il faut veiller à ne pas lui donner d'accès web.

Pour les ressources qui doivent être utilisés sur le web, tel que des 
css ou des JS, les scripts d'installations (de symfony par exemple) 
copient les fichiers concernés de vendor/ dans un répertoire accessible. 
Ça complexifie le processus mais ça évite d'ouvrir
des scripts PHP qu'on ne connaît pas, avec des chemins à rallonge en plus.


> Je n'ai pas encore clarifié mes idées mais je pense vraiment qu'on
> peut rendre l'idée de composer comme un simple type de lib et laisser
> le reste transparent.

L'autre difficulté c'est l'exécution de composer. Dans certains cas 
c'est réalisable en PHP, mais il est difficile de lire les sorties en 
temps réel, et d’interagir si une question apparaît. Alors qu'en 
terminal, c'est un outil très puissant.

MM.