[spip-dev] Piste de conception d'interface SPIP-Composer

[rastapopoulos]

J'ai enfin réussi à mettre au propre ce très modeste schéma que l'on a fait avec Charles lors de la formation Composer. Je pose ça là pour le moment, à copier ailleurs (Framavox, Contrib ou autre) quand il y aura un lieu unique et clair pour l'équipe qui veut réfléchir à Composer/Git.

Un peu d'explication :

Quand on parle "interface" pour Composer, il ne s'agit évidemment pas que d'ergonomie et de graphisme. Il s'agit aussi du mot "interface" en tant qu'une chose se trouve entre deux autres.

En effet, pour résumé, afin que des SPIP installés sur des hébergements basiques, ou sur des bons hébergements mais par des gens qui ne font pas en terminal, puissent utiliser la puissance des dépendances par Composer, alors il FAUT déléguer ce service à un serveur externe.

L'idée serait donc de développer un logiciel (libre), sans rapport avec SPIP, qui fournirait ce service sur "composer.spip.net". Pour l'instant il serait basique et tourné vers nos besoins prioritaires, mais ça peut intéresser potentiellement beaucoup de monde dans PHP, et d'autres personnes pourraient l'améliorer. Il se peut aussi que des gens aient déjà commencé des projets similaires (en libre !) : il faut regarder pour ne pas partir de zéro.

Quand les dépendances sont calculées, Composer génère un fichier "composer.lock" qui contient les liens vers les ZIP des bonnes versions de chaque modules. Avec ce fichier, nos SPIP sont capables comme maintenant de télécharger ces ZIP, et de les installer dans les bons dossiers.

Pour cela, /plugins (ou /plugins/auto) doit toujours être accessible en écriture, mais aussi /vendor pour toutes les libs qui ne sont pas propres à SPIP.

Il reste à résoudre le problème du "composer.lock" lui-même. En effet SPIP va en fournir un par défaut (contenant son noyau et les plugins-dist). Mais dès qu'on va ajouter des plugins et des libs tierces, ce fichier va changer ! Et donc il faut que SPIP soit capable d'écrire ce fichier et le modifier ! Cela dit, on n'est pas obligé de rendre la racine du SPIP en écriture pour ça : il suffit que CE fichier puisse être écrit, tout comme on demande à rendre dispo /IMG, /tmp etc.

À suivre !

[azerttyu]

Salut

Merci pour cette proposition qui pourrait aider à allier tout le monde

Dans le raisonnement , ne pas oublier une notion de fil d'attente. Si
on délègue le service à un tiers celui-ci risque d'être chargé , il
faudra donc bien penser à indiquer une notion de fil d'attente pour
obtenir le lock et ensuite les téléchargements.

En délégation on devrait aussi prendre en compte aussi le tiers local
pour ceux qui hébergent (sans nécessairement intervenir au niveau des
sites) cela permettrait d'avoir une gestion local

Km

[rastapopoulos]

Dans le raisonnement , ne pas oublier une notion de fil d'attente. Si
on délègue le service à un tiers celui-ci risque d'être chargé , il
faudra donc bien penser à indiquer une notion de fil d'attente pour
obtenir le lock et ensuite les téléchargements.

Oui, enfin le but c'est de pouvoir servir pas mal de monde d'un coup,
mais c'est certain que c'est un GROS chantier et compliqué avec ça.

Pour la partie composer.spip.net, c'est complètement hors SPIP, et même
si ça doit gérer des requêtes HTTP entrées-sorties, ya très peu de code,
ça va surtout être de l'admin sys, des lancements de commandes sur le
serveur. Personnellement je n'y connais RIEN là dedans, et donc ça me
fait peur.

Et c'est bien pour ça que j'insiste sur le fait qu'il faut commencer à y
réfléchir dès maintenant absolument, car c'est compliqué, et si on ne le
fait pas, ça signifie forcément perdre pendant longtemps la gestion des
plugins par interface (dès lors que des plugins vont commencer à
nécessiter des projets en Composer bien sûr). Hors d'après les retours
qu'on a commencé à avoir, mis à part quelques devs pros qui n'en ont pas
besoin (y compris moi hein), et bien ya pas beaucoup de monde qui a
envie de perdre ce moyen.

En délégation on devrait aussi prendre en compte aussi le tiers local
pour ceux qui hébergent (sans nécessairement intervenir au niveau des
sites) cela permettrait d'avoir une gestion local

Oui je suis assez d'accord, et ça ça devrait être côté "Plugin Composer"
sur mon schéma.

Si le plugin détecte que PHP accepte l'exec de la commande "composer",
ça pourrait alors utiliser tout en local au lieu de faire appel à un
service externe.

Du coup les gens sur un hébergement correct (pas OVH mutu quoi) qui
peuvent tout bien installer et configurer, pourraient quand même laisser
leurs utilisateurices chercher et installer des plugins par l'interface,
mais en autonomie.

Après ça pose des problèmes de sécurité quand même, ce n'est pas une
super bonne pratique (exec de commande qui peut écrire dès la racine…
hum…). Alors que la solution du schéma est un peu plus cadrée tout de
même, il me semble.

[azerttyu]

Salut

La solution locale avec exec ne sera pas bonne non plus. Cette
solution dépendra toujours du timeout apache, ce qu'on essaye de
contourner avec la solution proposée.
C'est peut être un script tiers avec un port dédié ou autre chose mais
en mon sens ce n'est pas au plugin de gérer le fonctionnement local,
il devrait juste savoir communiquer localement.

Les spécifications sont à déterminer bien sur et pour ma part je n'ai
pas réfléchi au delà de la proposition actuelle

Km

[marcimat (Matthieu Marcillaud)]

Pour rappel c’est exactement ce qu’à fait l’équipe Contao :

- https://medium.com/@yanick.witschi/composer-cloud-resolver-e64254f5728e

[rastapopoulos]

Je sais bien, puisqu'on en a déjà parlé pendant la formation. Sauf que
ce n'est pas libre, et même s'il donne un accès aux autres (avec limite)
pour le moment, ben ya rien qui permet de tout télécharger la même chose
pour l'installer sur son propre serveur.

Donc faut les contacter pour voir s'ils prévoient de le faire, mais si
ce n'est pas le cas, va bien falloir tout refaire…

Par ailleurs, il y a des nouveaux problèmes qui se posent : comme il le
dit bien, ça a un coût machine non négligeable (même si SPIP est pas
énormément utilisé mais ça peut ré-augmenter). Donc si nous on fournit
ce type de service, quelles limites on va donner ? Et faut que les gens
puissent définir leurs propres serveurs du même type aussi pour
décharger l'instance de la communauté.

Comme on le voit donc, pour fournir le même service qu'avant avec SVP
qui était autonome et ne coûtait rien en terme de mémoire, serveur, etc,
et bien là pour que les utilisateurs aient les mêmes possibilités, on se
retrouve à devoir mettre en place des trucs de ouf !

C'est quand même problématique, ça fait réfléchir… genre cool pour les
devs, mais quid de l'écologie, de la simplicité, de l'autonomie… Quand
on voit tout le boulot qu'il va falloir fournir pour juste obtenir comme
avant, ça parait pas très KISS… Moi perso ça m'interroge.

[RealET]

Matthieu Marcillaud a écrit le 01/04/2019 à 09:53 :

Pas en libre ; du moins pour le moment. Et extensible dans les nuages (docker + kumbernetes)

Certes, mais il est ouvert à la discussion avec d'autres CMS :
« However, I’m totally open for discussions! So if you’re working on some sort of project that has the same issue like WordPress, Drupal, Typo3 etc. I think we should talk »

[JLuc]

Moi je m'interroge sur la qualité de Composer.
Pas évident ni basique, mais la gestion d'un graphe de dépendances
semble être un problème algorythmique très classique.
Qu'est ce qui nécessite donc des ressources mémoire et matérielles
aussi lourdes ?

JL

[rastapopoulos]

Euh faut pas exagérer… Composer gère un graphe beaucoup plus gros que ce
que nous on gérait, et y compris par rapport à la version de PHP
installé, enfin ya plein de contraintes. C'est le cœur de l'éco-système
PHP depuis des années, c'est utilisé littéralement par des millions de
gens et maintenu par beaucoup aussi, donc je ne m'inquiète absolument
pas de la qualité et de la pérennité de Composer lui-même.

Moi là je parle de *l'ensemble* de ce qu'il faut mettre en œuvre pour
juste arriver à avoir un truc iso-fonctionnel : pouvoir chercher et
installer des plugins depuis l'interface d'un SPIP. Et là ça parait
foufou tout ce qu'il faut faire (et qu'on a pas encore, et qui n'existe
toujours pas en libre) pour arriver à obtenir ce qu'on avait avec SVP,
et que la plupart de nos utilisateurices ne veulent pas perdre.

Mais on perd aussi énormément en s'isolant de Composer pour les plugins
(pour le core c'est bon c'est pas un problème)… Bref, ça fait encore
réfléchir…
(Je le redis encore pour que ce soit hyper clair, je parle pas du core,
mais bien de comment on va continuer à développer nos plugins.)