Re: Composer et SPIP sont dans un bateau

Le 18/03/2019 à 16:48, Matthieu Marcillaud a écrit :
> Le 18/03/2019 à 15:54, Maïeul a écrit :
> 
>> Il y a un truc que je ne comprend pas très bien, c'est la distinction 
>> entre les deux types de plugins "Composer" et "interface".  Pourquoi 
>> est-ce qu'on ne pourrait pas avoir une interface graphique pour 
>> composer ?
> 
> C’est vrai que j’ai omis de détailler cela, mais Composer fait 3 choses :
> 
> - A) à partir d’une liste de dépendances racines, de contraintes, il 
> calcule l’ensemble de toutes les dépendances qui sont nécessaires au 
> projet. Il en écrit un composer.lock
> - B) à partir de ça il va comparer ce que tu as en local avec le 
> composer.lock et mettre à jour ou télécharger (en zip ou sources) ce 
> dont tu as besoin.
> - C) des plugins composer peuvent exécuter des actions sur certains 
> événements (déplacement de fichiers, vidage de cache, etc...)
> 
> La partie A) (le SAT https://fr.wikipedia.org/wiki/Probl%C3%A8me_SAT) 
> est très gourmande en ressources, notamment en mémoire PHP
> 
> La partie B) peut prendre du temps (notamment si ça télécharge des 
> sources GIT), mais n’a pas besoin de beaucoup de mémoire (mais a besoin 
> de droits d’écriture sur certains répertoires).
> 
> La partie C) peut nécessiter des droits spécifiques.
> 
> Utiliser Composer avec une interface graphique revient à résoudre ces 3 
> points ; sachant que l’équipe Composer ne souhaite pas d’interface 
> graphique pour des questions de sécurités (permettre de télécharger 
> n’importe quoi facilement sur un hébergement est rarement bien vu en 
> terme de sécurité).
> 
> Évidemment certains outils (CMS) se sont quand même penchés sur la 
> question, que nous citons dans l’article. A minima cela revient à 
> calculer A sans dépasser le memory-limit (en le sous-traitant à un autre 
> serveur par exemple), à appliquer B) et à désactiver C) totalement.
> 
ok, je comprend mieux. Mais du coup cela voudrait dire qu'on pourrait 
utiliser composer pour par ex generer des distributions SPIP depuis un 
serveur, gérer des dépendances à des lib externes pour un plugin, mais 
pas forcément pour installer des plugins sur un site, car cela serait 
trop gourmand. Et là on resterait sur du SVP traditionnel, qui irait 
chercher des "packs" tout fait de plugins et de dépendance, qui eux 
seraient gérés par composer sur le serveur distant?

> 
> 
>> Une remarque aussi, plus politique. Pourquoi entre Gitlab (libre, 
>> ouvert) et Github (propriétaire), choisir le second?
> 
> Ça a été un grand débat déjà de suggérer de préférer Github.com ou 
> Gitlab.com pour faciliter l’utilisation de Composer.
> 
> Mais pour cette question spécifique, il me semble que c’est la mémoire 
> collective qui a jouée en considérant que Github incarne (ou incarnait) 
> le plus l’esprit Open source et que la plupart des gens y ont un compte.
> 
> Après, Gitlab est aussi une grosse entreprise. Au moins le logiciel 
> Gitlab existe pour le moment en version communautaire open source.

c'est surtout sur ca que je me pose la question, comment on fait pour ne 
pas être dépendant de github, et pouvoir se barrer facilement. Après 
oui, Gitlab est pas une boite non plus top....
> 
> (et donc pour ma part, peut importe, tant qu’on va quelque part…)
> 
> MM.
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip


_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip