Salut,
Fin février, certain·es d’entre nous se sont réunis quelques jours pour parler de Composer.
En voici un petit compte-rendu :
https://blog.spip.net/Composer-et-SPIP-sont-dans-un-bateau.html
Retour sur cette même liste bienvenus. 
Amitiés,
Salut,
merci pour le travail effectué et la pédagogie mise en place (dont ce billet) pour que tout le monde puisse suivre cette évolution majeure qui semble indispensable pour l'avenir de l'écosystème SPIP.
jeanmarieMerci pour ce CR.
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 ?
Une remarque aussi, plus politique. Pourquoi entre Gitlab (libre, ouvert) et Github (propriétaire), choisir le second?
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 Problème SAT — Wikipédia) 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.
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.
(et donc pour ma part, peut importe, tant qu’on va quelque part…)
MM.
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 Problème SAT — Wikipédia) 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....
É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.
En terminal ce n’est pas un problème (on peut faire installer les plugins dans le répertoire plugins/ ou plugins-dist/ même).
On peut même packager des zips tout prêts de distributions SPIP alternatives pour les utiliser ensuite avec spip-loader éventuellement.
C’est effectivement l’ajout depuis une interface graphique qui est ensuite délicate. La suggestion de séparer des paquets «graphiques» sans dépendances est une possibilité (des thèmes, des squelettes par exemple) en continuant d’utiliser SVP pour eux (à mon avis on sera très limité quand même car quantité de plugins ont des dépendances) (et aussi parce qu’il faudrait que les gens puissent télécharger graphiquement «Formidable» par exemple qui a tout un tas de dépendances lui-même) ; mais il faudrait que ça soit transitoire pour ne pas avoir à terme à gérer 2 systèmes.
C’est aussi pour cela la suggestion de la conclusion. Il pourrait y avoir une distribution SPIP «mature» qui continue de fonctionner comme actuellement, pendant qu’un autre morceau (le noyau) explore de nouvelles possibilités. Mais bon, on le voit bien aussi encore aujourd’hui, les plugins de la zone ont besoin de Composer (pas que le core ni les plugins-dist).
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?
Non. Du tout. En tout cas on ne pourrait pas intégrer des packs qui auraient aussi un répertoire vendor/ dedans. Ça risquerait de créer des conflits et en plus on ne saurait pas faire le merge.
Il faut laisser Composer gérer le calcul et le téléchargement des dépendances (il est vraiment fait et optimisé pour ça).
Je suis pas forcément très clair dans ce que j’exprime, mais tout n’est pas encore clair dans comment faire après 
MM.
> >
> > É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.En terminal ce n’est pas un problème (on peut faire installer les
plugins dans le répertoire plugins/ ou plugins-dist/ même).
On peut même packager des zips tout prêts de distributions SPIP
alternatives pour les utiliser ensuite avec spip-loader
éventuellement.C’est effectivement l’ajout depuis une interface graphique qui est
ensuite délicate. La suggestion de séparer des paquets «graphiques»
sans
dépendances est une possibilité (des thèmes, des squelettes par
exemple)
en continuant d’utiliser SVP pour eux (à mon avis on sera très limité
quand même car quantité de plugins ont des dépendances) (et aussi
parce
qu’il faudrait que les gens puissent télécharger graphiquement
«Formidable» par exemple qui a tout un tas de dépendances lui-même) ;
mais il faudrait que ça soit transitoire pour ne pas avoir à terme à
gérer 2 systèmes.
oui, perso les squelettes que je dev ont tous des dépendances...
C’est aussi pour cela la suggestion de la conclusion. Il pourrait y
avoir une distribution SPIP «mature» qui continue de fonctionner
comme
actuellement, pendant qu’un autre morceau (le noyau) explore de
nouvelles possibilités. Mais bon, on le voit bien aussi encore
aujourd’hui, les plugins de la zone ont besoin de Composer (pas que
le
core ni les plugins-dist).> 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?Non. Du tout. En tout cas on ne pourrait pas intégrer des packs qui
auraient aussi un répertoire vendor/ dedans. Ça risquerait de créer
des
conflits et en plus on ne saurait pas faire le merge.Il faut laisser Composer gérer le calcul et le téléchargement des
dépendances (il est vraiment fait et optimisé pour ça).
Je suis pas forcément très clair dans ce que j’exprime, mais tout
n’est
pas encore clair dans comment faire aprèsMM.
Donc cela voudrait dire que sans composer, pas de gestion de
dépendance...
Ce que je comprend moyen, c'est la nécessité de composer pour gérer les
dépendances interne au monde SPIP. Pour une dépendance externe, oui, ca
a du sens. Mais pour une dépendance interne...
C’est pour éviter de maintenir notre propre système de gestion de dépendances de notre côté (qui est loin d’être aussi robuste). Ce n’est pas spécialement une obligation effectivement. En tout cas dans un premier temps.
Mais c’est aussi parce que Composer fait un poil plus que ce qu’on a dit (résolution de dépendances & téléchargements).
Notamment il calcule aussi un «autoloader», basé sur les différentes déclarations des fichiers composer.json. Et assez certainement, on en aura besoin dans l’avenir dans les plugins.
MM.
> Ce que je comprend moyen, c'est la nécessité de composer pour gérer
> les
> dépendances interne au monde SPIP. Pour une dépendance externe, oui,
> ca
> a du sens. Mais pour une dépendance interne...
>C’est pour éviter de maintenir notre propre système de gestion de
dépendances de notre côté (qui est loin d’être aussi robuste). Ce
n’est
pas spécialement une obligation effectivement. En tout cas dans un
premier temps.
ca pose des soucis politiques / editorial, de devoir avoir composer sur
n'importe quel serveur qui hébergement
Mais c’est aussi parce que Composer fait un poil plus que ce qu’on a
dit
(résolution de dépendances & téléchargements).
Notamment il calcule aussi un «autoloader», basé sur les différentes
déclarations des fichiers composer.json. Et assez certainement, on en
aura besoin dans l’avenir dans les plugins.
c'est à dire?
Le 18/03/2019 à 18:23, Maïeul Rouquette a écri
ca pose des soucis politiques / editorial, de devoir avoir composer sur
n'importe quel serveur qui hébergement
Je te retourne ton «c’est à dire ?».
Composer n’a pas besoin de permissions d’administrateur du serveur pour fonctionner (c’est un fichier php… enfin une archive .phar) ; si c’est la question ?
Mais c’est aussi parce que Composer fait un poil plus que ce qu’on a
dit
(résolution de dépendances & téléchargements).
Notamment il calcule aussi un «autoloader», basé sur les différentes
déclarations des fichiers composer.json. Et assez certainement, on en
aura besoin dans l’avenir dans les plugins.c'est à dire?
Ok, détaillons (rapidement).
Un autoloader en PHP, c’est une déclaration qui permet de dire :
- si j’appelle telle classe `new Toto()` ou `new Auto\Mobile()`,
- que je la connais pas encore en mémoire,
- alors, elle se trouve dans tel fichier ; vas-y : charge ce fichier automatiquement !
En gros ça pourrait remplacer potentiellement certains include() ou include_spip().
Un intérêt, c’est que tu vas déclarer en tête de fichiers toutes les classes que tu pourrais utiliser dans ton fichier (ce n’est pas une obligation non plus) avec l’instruction `use` :
Ici, tu pourrais avoir `use Auto\Mobile;` ou `use Auto\Mobile as Automobile;`, et plus loin quelque part dans ton code `$auto = new Mobile();` ou `$auto = new Automobile();` (ou toute autre instruction indiquant une classe quelque part)
Le fichier contenant la description de la classe Auto\Mobile ne serait chargé (si besoin) que si la ligne new Mobile() est réellement exécutée.
Autrement dit, les `use` ne sont pas comme des include ou des require. Ça dit juste, j’aurais probablement besoin de ça — fais-moi en un raccourci ; grosso modo.
Et pour savoir la correspondance entre le nom de la classe, et le fichier à rechercher, il n’y a pas de mystère : cela s’appuie sur, maintenant essentiellement PSR-4 (PSR-4: Autoloader - PHP-FIG), et une déclaration dans les fichiers composer.json.
Ainsi tu pourrais avoir `autoload: { "psr-4": { "Auto\\": "src/" } }` dans le composer.json du plugin… disons "Auto"… :
Ça dit en gros, cherche ce qui concerne le namespace "Auto/" dans le répertoire src/ ici présent…. Ça sous-entendrait qu’il existe le fichier "src/Mobile.php" avec la classe Auto/Mobile dedans.
Note que toutes les librairies PHP utilisent ça maintenant et déjà depuis quelques temps quand même.
Il me semble (mais là encore ce n’est qu’un avis perso) que nous aurions intérêt à nous harmoniser avec les autres un peu
MM.
Note que toutes les librairies PHP utilisent ça maintenant et déjà depuis quelques temps quand même.
Librairies et frameworks, c'est en partie aussi cette méthode standard qui les rend interopérables, qu'on peut les utiliser les unes avec les autres sans trop se poser de question, que les éditeurs de code moderne les reconnaissent et proposent de l'autocomplétion etc.
Il me semble (mais là encore ce n’est qu’un avis perso) que nous aurions intérêt à nous harmoniser avec les autres un peu
Oui, totalement.
Et nous pourrions réécrire certains gros plugins sous cette forme (saisies, ...), ce qui ouvrirait des portes (tests unitaires etc.).
Salut
Merci pour ce retour.
Je me permets 1 remarque et 1 question :
La première personnelle, c'est ce choix de SASS avec github/gitlab par
défaut. Je pense toujours que c'est une bêtise mais celui qui code qui
a raison.
La seconde si je comprends bien l'idée on aurait 2 zones de
téléchargement distinctes une pour SVP et l'autre pour composer.
Comment va se gérer la maintenance d'un plugin ? Un plugin installé
par composer serait hors écosystème SVP (et pas réciproquement) cela
me semble un coût important sans avancée notable. En l'état un plugin
SVP n'a pas de vraie raison de passer en plugin Composer. Et un plugin
composer sera restreint aux terminaux serveurs.
Je vois l’intérêt pour les plugins-dist qui sont fournis par défaut
dans l'archive SPIP (donc pas de conflit avec SVP) et ouvre la
possibilité d'avoir enfin des distributions dont on court après depuis
des années.
Là où je coince c'est le principe de la transition, à moyen/long terme
je vois toujours 2 solutions à maintenir et non un remplacement, et
cela du fait des contraintes propres à composer. Et donc je
m'interroge sur l'intérêt de la bascule tant pour les développements
que pour les usages des plugins .
Je me base sur le compte rendu vu que j'ai malheureusement pu venir ,
discuter , échanger et comprendre.
Merci encore pour le travail
Km
Salut
Merci pour ce retour.
Je me permets 1 remarque et 1 question :
La première personnelle, c'est ce choix de SASS avec github/gitlab par
défaut. Je pense toujours que c'est une bêtise mais celui qui code qui
a raison.
Il y avait plusieurs raisons discutées à cela, entre autres et avant tout car c’est plus simple pour Composer avec Packagist.org, et aussi le fait de s’éviter de la maintenance.
La seconde si je comprends bien l'idée on aurait 2 zones de
téléchargement distinctes une pour SVP et l'autre pour composer.
Distinguons d’abord la première partie du plan (core + plugins-dist). Celle-ci ne pose pas trop de problème il semblerait.
On aurait le zip habituel (avec peut être un vendor/ en plus selon ce qu’on utiliserait comme librairie de base), et le reste serait géré par SVP comme actuellement.
C’est la suite logique (mais un peu plus lointaine) qui est plus discutable (utiliser Composer aussi pour les autres plugins).
Effectivement, pendant un temps on se retrouverait avec 2 sortes de plugins,
- une capable d’être utilisée avec Composer,
- l’autre capable d’être utilisée avec SVP,
- et des plugins à l’intersection des deux
Comment va se gérer la maintenance d'un plugin ? Un plugin installé
par composer serait hors écosystème SVP (et pas réciproquement)
Assez probablement un plugin installé par composer (en terminal) ne pourrait pas être mis à jour par interface graphique (SVP ou un descendant de SVP utilisant une interface graphique avec Composer), quoi que je ne suis pas sûr que ça soit impossible.
cela
me semble un coût important sans avancée notable. En l'état un plugin
SVP n'a pas de vraie raison de passer en plugin Composer. Et un plugin
composer sera restreint aux terminaux serveurs.
Oui, mais ce raisonnement se base sur les plugins actuels qui ne peuvent pas utiliser Composer actuellement ! (Ou qui tentent de le faire difficilement en fournissant eux-même un répertoire vendor/ ce qui a toutes les chances de péter… il y en a 3 comme ça sur la zone déjà). L’avancée, me semble-t-il, c’est justement de pouvoir récupérer et utiliser des librairies externes facilement. Et de faire évoluer nos plugins.
[...]
Là où je coince c'est le principe de la transition, à moyen/long terme
je vois toujours 2 solutions à maintenir et non un remplacement, et
cela du fait des contraintes propres à composer.
Oui. Et cette transition n’est pas encore très claire.
Et donc je
m'interroge sur l'intérêt de la bascule tant pour les développements
que pour les usages des plugins .
Bah, on peut aussi apprendre à se contenter de ce qu’on a, après tout, ça fonctionne encore
Mais personnellement, ce grand écart en SPIP et le reste du monde PHP commence à me taper grave sur le système, alors je suis plutôt content de cette direction vers Composer.
Mais ça n’a pas l’air de satisfaire tellement ici au final. Peut être qu’on fait fausse route.
MM.
Hello,
Bah, on peut aussi apprendre à se contenter de ce qu’on a, après tout,
ça fonctionne encore
Mais personnellement, ce grand écart en SPIP et le reste du monde PHP
commence à me taper grave sur le système, alors je suis plutôt content
de cette direction vers Composer.
Mais ça n’a pas l’air de satisfaire tellement ici au final. Peut être
qu’on fait fausse route.
Je ne crois pas qu’on puisse dire cela.
Une nouvelle route est proposée et c’est vrai qu’au fil des discussions on comprend mieux ce qui nous attend si on y va.
Et franchement c’est évident que cela ne peut pas plaire à tous car les impacts sont différents selon que l’on est développeur du Core/dist, développeur de plugin, intégrateur, webmestre ou rédacteur.
Il faudrait peut-être mieux séparer les variables en distinguant les avantages et inconvénients suivant le profil d’utilisation.
Après dans la roadmap proposée il y a des choses que je ne comprends pas comme :
-
l’étape Core + Plugins Dist en composer et les reste en SVP qui semble pouvoir s’éterniser. Déjà il nous arrive parfois de décider d’intégrer un plugin dans la dist et d’autre part quid des distributions qui étendraient la base (core+dist) ? Donc avons nous l’ambition de passer tout en Composer et sinon le système proposé à deux vitesses a t-il un sens ?
-
Je suis étonné de la difficulté à imaginer une interface « type SVP » qui fonctionnerait en Composer. Quel est l’état de l’art des autres CMS comme Drupal, Joomla, Wordpress… Y en a t-il qui aurait abandonné leur interface de gestion de plugins (si elle existe) pour se « revenir » à de la ligne de commande ? C’est vrai que quand on vous lit on se dit qu’on retrouvera jamais un SVP vu les problématique technique lié à Composer. C’est quand même embêtant mais si ce n’est pas rédhibitoire au début.
-
Ensuite je pense à Plugins SPIP. On fait des efforts ces derniers temps sur l’amélioration et la cohérence de la documentation de la galaxie et en particulier de celle des plugins. Si plus de SVP ou si SVP ne couvre qu’une partie des plugins comment assurer la complétude de la documentation et par exemple de Plugins SPIP ?
Je pense que ce sujet n’est pas anodin.
Tout ça pour dire qu’il est toujours facile de voir ce qu’on perd et moins ce qu’on y gagne surtout si on est pas expert.
Et pour l’instant malgré les efforts j’avoue que l’on a du mal à rassurer et à communiquer l’enthousiasme de certains qui est surement justifié.
- Je suis étonné de la difficulté à imaginer une interface "type SVP" qui fonctionnerait en Composer. Quel est l'état de l'art des autres CMS comme Drupal, Joomla, Wordpress... Y en a t-il qui aurait abandonné leur interface de gestion de plugins (si elle existe) pour se "revenir" à de la ligne de commande ? C'est vrai que quand on vous lit on se dit qu'on retrouvera jamais un SVP vu les problématique technique lié à Composer. C'est quand même embêtant mais si ce n'est pas rédhibitoire au début.
oui. c'est le point crucial. Parce que plus de SVP ou autre graphique > on perd les utilisateureuses habituel de SPIP, sans gagner en plus les gens du monde PHP (qui viendront pas vers nous juste parce qu'on a des outils plus proches d'eux, il y aussi des choses dans la manière dont SPIP fonctionne en terme de codage qui le rendent disons... particulier)
- Je suis étonné de la difficulté à imaginer une interface « type SVP »
qui fonctionnerait en Composer. Quel est l’état de l’art des autres CMS
comme Drupal, Joomla, Wordpress… Y en a t-il qui aurait abandonné leur
interface de gestion de plugins (si elle existe) pour se « revenir » à de
la ligne de commande ? C’est vrai que quand on vous lit on se dit qu’on
retrouvera jamais un SVP vu les problématique technique lié à Composer.
C’est quand même embêtant mais si ce n’est pas rédhibitoire au début.oui. c’est le point crucial. Parce que plus de SVP ou autre graphique >
on perd les utilisateureuses habituel de SPIP, sans gagner en plus les
gens du monde PHP (qui viendront pas vers nous juste parce qu’on a des
outils plus proches d’eux, il y aussi des choses dans la manière dont
SPIP fonctionne en terme de codage qui le rendent disons… particulier)
Hello.
J’ai suivi un peu le fil de discussion. Et la grosse « problématique » semblerait une possible interface pour Composer… Ça existe :
https://www.getcomposercat.com
Il faut voir de cela, ce qui est utilisable pour SVP/Composer et le besoin de SPIP (est-ce qu’on limite aux packages liés à SPIP ?)
Je n’ai pas creusé, mais on m’a soufflé à l’oreille qu’AngularJS avait la problématique composer + leurs propres répertoires.
On m’a donné en exemple ces urls :
A creuser peut-être.
Ybbet.
Je copie un de mes coms du blogs (obligé puisque répondant à des gens là
bas).
1) Historiquement, la ligne de commande n'est pas un retour en arrière,
ça dépend complètement de quels publics on parle. La ligne de commande a
toujours été et est *plus que jamais* l'outil de base des
développeur⋅euses, et depuis quelques années tout autant des
intégrateurices. Tous les projets PHP de nos jours s'installent avec
Composer, et la majorité des outils d'intégrations (frameworks JS, CSS
etc) s'utilisent en ligne de commande avec l'écosystème Javascript NPM.
Et cela vaut aussi bien pour les devs/inté lors de la construction d'un
site/d'une appli que pour celleux qui déploient et maintiennent les
choses en ligne (les admins sys). Quand on dit "outils modernes" dans le
monde du dev et de l'inté, c'est justement que des trucs en ligne de
commande.
*MAIS* ça c'est pour le monde "super pro", moyen et gros projets, où il
y a des compétences très découpées. Il n'en reste pas moins qu'il
continue d'y avoir de nombreuses intégrateurices (et même parfois des
boites de plusieurs personnes !) qui ne font que de l'intégration
classique de base, et qui utilisent SPIP depuis des années uniquement en
interface pour l'installer et le maintenir chez leurs clients.
(M'est-avis que ce public se réduit d'année en année tout de même.)
Ainsi que des utilisateurices associations, site perso, PME ou autre,
qui font tout en interne, en bidouillant. Si on veut garder ces publics,
les interfaces doivent exister que ce soit pour l'installation de SPIP
(ce sera toujours ok avec spip_loader on a dit donc stop) ET des plugins
(c'est là le truc compliqué).
2) Quand on parle d'interface pour Composer, il s'agit d'un chantier
purement de devs, de code, de délégation de système, d'admin sys. C'est
ça le truc à résoudre. Pour l'ergonomie ça n'a strictement aucun rapport
avec cette discussion. Au pire ça peut rester sensiblement pareil
visuellement, et au mieux ça à un rapport avec un chantier de refonte
ergo de l'admin. Donc pour ce chantier précis là, on n'a (pour
l'instant) pas besoin de compétence en ergonomie ou en intégration, ce
n'est pas le cœur du problème.
3) Comme je l'ai déjà dit précédemment, il ne faut pas rester que sur
cette différence entre "méga pro moderne" et "simple inté" ou
"bidouilleureuse". En effet, même pour des sites qui auraient été
développés par une grosse équipe avec des outils modernes ET mis en
ligne par des admins sys avec des outils modernes : les plugins DOIVENT
pouvoir être cherchés et installés par une interface, car de nombreux
plugins sont des *choix éditoriaux* qui peuvent donc être faits par des
admins (au sens SPIP) sans aucun rapport avec la technique.
Bref, mon avis général est que pour noyau, on est bon. Mais que pour les
plugins, on ne doit pas aller vers Composer tant qu'on n'a pas déjà une
interface utilisable sous la main. Pour *aucun plugin*, car de toute
façon ils se nécessitent tous les uns les autres, et les squelettes
génériques partagés nécessitent tous aussi des plugins fonctionnels.
On ne peut pas perdre de manière certaines N% des utilisateurices pour
un gain qui lui est seulement hypothétique.
Attention : le gain pour les quelques devs de SPIP qui vont pouvoir
s'amuser à nécessiter des libs externes est sûr à 100% mais illes se
comptent sur les doigts des mains ! En revanche le gain de nouveaux
utilisateurices qui viendraient parce qu'on serait en Composer, lui est
totalement hypothétique.
Si on dit "SPIP doit *permettre* de ne pas avoir d'interface pour
installer et mettre à jour", je suis totalement d'accord ! Sauf que si
on dit que pour l'instant on part là-dessus sans en avoir et que c'est
aux gens qui en ont besoin de le développer plus tard, ça n'a rien à
voir ! Là ce n'est plus permettre, c'est *obliger* à ne pas avoir
d'interface, et rendre hypothétique l'arrivée d'une interface plus tard.
Ça n'a donc rien à avoir avec la phrase de départ. (Et je suis contre.)
Très bien explicité ! +++
Et bravo pour les bidouilheureux !
Je suis assez d’accord avec tes remarques. Du coup, je vais couper pas mal de morceaux.
1) Historiquement
[...] font que de l'intégration
classique de base, et qui utilisent SPIP depuis des années uniquement en
interface pour l'installer et le maintenir chez leurs clients.
(M'est-avis que ce public se réduit d'année en année tout de même.)
C’est une quasi-certitude même au vu des évolutions de la liste spip-user
[En plus, les pages Facebook (hic) sont souvent utilisées pour la plupart des petites structures, au moins au début].
2) Quand on parle d'interface pour Composer, il s'agit d'un chantier
purement de devs [...]
Et de temps à y consacrer
3) [...] les plugins DOIVENT pouvoir être cherchés et installés par une interface
Des plugins ou tous les plugins ?
C’est un des sens de la distinction qui était faite ; les plugins vont utiliser des librairies aussi issues de Composer (ils le font déjà en plus certains, vilainement en envoyant un répertoire vendor/) ; Comment pourrait-il en être autrement vu que toutes les libs partout sont passées à des dépendances via Composer ?
Bref, mon avis général est que pour noyau, on est bon. Mais que pour les
plugins, on ne doit pas aller vers Composer tant qu'on n'a pas déjà une
interface utilisable sous la main. Pour *aucun plugin*, car de toute
façon ils se nécessitent tous les uns les autres, et les squelettes
génériques partagés nécessitent tous aussi des plugins fonctionnels.
C’est là où on n’est moins d’accord. Surtout par le fait que c’est absurde de pas pouvoir profiter de Composer dans nos plugins, vu qu’on est déjà bridé par cette absence. Attendre d’avoir une interface graphique de remplacement fonctionnelle (pour tous les plugins), c’est repousser encore des évolutions de code et de fonctionnalités pour longtemps…
On ne peut pas perdre de manière certaines N% des utilisateurices pour
un gain qui lui est seulement hypothétique.
[...]
Tout est hypothétique… même le fait de perdre N% des utilisateurices… qui seraient déjà partis de toutes façon pour plein d’autres bonnes raisons…
Si on dit "SPIP doit *permettre* de ne pas avoir d'interface pour
installer et mettre à jour", je suis totalement d'accord ! Sauf que si
on dit que pour l'instant on part là-dessus sans en avoir et que c'est
aux gens qui en ont besoin de le développer plus tard, ça n'a rien à
voir ! Là ce n'est plus permettre, c'est *obliger* à ne pas avoir
d'interface, et rendre hypothétique l'arrivée d'une interface plus tard.
Ça n'a donc rien à avoir avec la phrase de départ. (Et je suis contre.)
J’entends bien. Soit. L’interface graphique à disposer *pour tous les plugins*, tu le contraints aussi aux développeureuses comme pré-requis pour aller plus loin.
Mais je sais pas si on peut aller très loin comme ça
MM.
merci Rasta, je suis totalement d'accord.