Re: Composer et SPIP sont dans un bateau

Le 20/03/2019 à 12:31, RastaPopoulos a écrit :

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.





_______________________________________________
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