Salut tout le monde
De mon coté je m'appuie de plus en plus souvent sur composer et les
bibliothèque de https://packagist.org/
Pour ceci j'aimerai fair un plugin qui s'interface avec paquet.xml
pour rajouter une option à <lib>
Est ce possible ?
Si oui comment étendre SVP/paquet.xml ?
Si non comment intégrer cett eposibilité ?
Km
Pas de réponse que le XML, mais juste pour dire de pas commencer un nouveau truc, il y a déjà un plugin Composer sur la zone, démarré par Marcimat ya 2 mois.
http://zone.spip.org/trac/spip-zone/browser/plugins/composer/trunk
Actuellement le plugin de Marcimat il demande à déclarer le paquet qu'on veut dans un pipeline. Toi tu voudrais étendre le XML pour permettre ça sans pipeline, si je comprends bien. Je ne sais pas si c'est vraiment obligatoire, le pipeline c'est juste 3 lignes à faire, mais bon, si on "officialise" ça, et qu'on arrive à faire un truc propre, ça peut effectivement être bien de le permettre dès le XML…
Donc à discuter (sur spip-zone ?) pour voir comment faire fonctionner ça au mieux… J'avais commencé à regarder, et je m'étais dit que pour l'instant je n'étais pas fan de comment ça marchait (mais oui ce n'est qu'un début…), avec le JSON produit, et les trucs installés dans vendor/ à la racine.
Possiblement des pistes de solutions là :
https://github.com/composer/composer/issues/1906
là
https://github.com/CurosMJ/NoConsoleComposer/blob/master/composer/main.php
et là
http://stackoverflow.com/questions/17219436/run-composer-with-a-php-script-in-browser
En gros la solution c'est : inclure *le PHP* de Composer dans le plugin (enfin ça peut être en fournissant un JSON qui va le chercher, mais justement là le but c'est d'avoir un plugin qui s'installe comme un plugin SPIP normal mais qui ensuite va savoir chercher les paquets *tout seul*), et utiliser ce PHP comme une application Console (ça utilise Console de Symfony en fait), en fournissant $input et $output puis $composer->run().
Salut
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
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.
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.
Km
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.
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.