[spip-dev] Composer et SPIP sont dans un bateau

Hello,

L'ensemble de mon email argumente sur des faits, qui aboutissent à des
conséquences.

Alors on peut me répondre en prouvant que mon raisonnement est faux, et
ce serait justement super ! Puisque ça signifierait que le travail est
finalement plus simple que je ne le pense pour l'instant, tant mieux ! \o/

Mais insinuer que ce que j'ai dit n'est pas du raisonnement
("littérature") mais des commentaires sur des intentions subjectives
(dont je me fous complètement), et que le but en listant des problèmes
majeurs ce serait de démotiver les gens pour que ça n'avance pas : c'est
clairement *ça* la calomnie, pour celleux qui n'auraient pas eu le temps
de lire tout mon message ou qui n'en comprendraient pas les enjeux.

D'autant plus que ce n'est vraiment pas faute de bonne volonté : avec
Charles nous avions immédiatement commencé à concevoir, pendant la
formation, une piste de solution pour arriver à fournir un service
d'interface graphique pour Composer. On a longuement discuté avec James,
on lui a posé plein de questions, et il ne me semble pas qu'il ait de
doute sur notre motivation à résoudre ce problème. Ça fait un mois qu'on
doit mettre le schéma au propre, malheureusement (je viens seulement de
le faire…).

Mais ce n'est pas parce qu'on est motivé qu'il faut se voiler la face.
Et pour le moment, suivant les faits actuels, et le but à relativement
court terme (pouvoir utiliser des projets tiers avec Composer dans les
plugins), le raisonnement aboutit à ce que ces plugins ayant des
dépendances Composer ne puissent être installés avec SVP, donc à être de
fait inaccessibles par interface puisqu'on n'a pour l'instant pas
d'interface pour Composer. Et donc si on ne veut pas perdre les gens qui
ont besoin d'interface pour les plugins (plein de gens), et bien il faut
arriver à développer cette solution dès le début (car c'est un gros
chantier compliqué), on ne peut pas se permettre de le reléguer aux
calendes grecques : sinon on aura pendant un temps indéfini un SPIPVIP
dont la plupart des plugins ne pourront s'installer qu'en terminal.

Bref ya deux tâches compliquées à résoudre dès maintenant :
- les traductions vers Git
- une interface pour Composer

Hello,

Bref ya deux tâches compliquées à résoudre dès maintenant :

  • les traductions vers Git
  • une interface pour Composer

Je viens de relire l’article de James suite à la réunion Composer.
J’ai toujours du mal à sentir véritablement les difficultés de la mise en oeuvre et surtout le temps qu’une migration complète (pour retrouver un système similaire à SVP) prendrait.

Si on fait un premier pas :

  • passage de spip sous GIT et composer
  • passage des plugins-dist sous GIT et composer
    et uniquement cela on est plus ou moins dans le même état qu’aujourd’hui car finalement on installe sous zip ou avec SVN toujours l’ensemble des ces composants d’un coup (spip_loader ou externals SVN), non ?

Si c’est bien le cas, pourquoi ne pas s’arrêter à ce stade tant que nous n’avons pas un SVP Composer ?
Tant pis, les autres plugins attendront pour bénéficier des facilités de Composer et ce sera à nous de faire en sorte de réduire ce temps de latence.
Est-ce faisable et si oui acceptable ?

Par contre, je trouve qu’aujourd’hui la séparation entre plugins-dist et autres plugins sous SVN n’est pas très heureuse. C’est compliqué aussi quand on décide de passer en plugins-dist un nouveau plugin et la notion de distribution est toujours en panne.
Si je comprends bien James propose de créer une organisation “spip” qui contiendrait le core et les plugins-dist.
Est-ce qu’on est pas en train là de reproduire le même schéma pas très pratique que l’actuel sous SVN ?
Pourquoi ne pas avoir une organisation “plugins” qui contiendrait tout d’abord les plugins-dist qu’on installe aujourd’hui par défaut et qui serait complétée plus tard lorsque le SVP Composer serait opérationnel ?

A votre avis, j’ai rien compris ? Ca a du sens ou pas ?

Si on fait un premier pas :
- passage de spip sous GIT et composer
- passage des plugins-dist sous GIT et composer
et uniquement cela on est plus ou moins dans le même état qu'aujourd'hui
car finalement on installe sous zip ou avec SVN toujours l'ensemble des
ces composants d'un coup (spip_loader ou externals SVN), non ?

SVN c'est finished :slight_smile:

Donc gros ZIP tout compris par spip_loader oui.
Ou par composer install pour celleux qui veulent en terminal.

Si c'est bien le cas, pourquoi ne pas s'arrêter à ce stade tant que nous
n'avons pas un SVP Composer ?
Tant pis, les autres plugins attendront pour bénéficier des facilités de
Composer et ce sera à nous de faire en sorte de réduire ce temps de latence.
Est-ce faisable et si oui acceptable ?

Oui c'est la première étape de prévue.

Pourquoi ne pas avoir une organisation "plugins" qui contiendrait tout
d'abord les plugins-dist qu'on installe aujourd'hui par défaut et qui
serait complétée plus tard lorsque le SVP Composer serait opérationnel ?

A votre avis, j'ai rien compris ? Ca a du sens ou pas ?

Pour les plugins-dist, ce n'est pas tant un problème technique mais de
choix de gouvernance.

Est-ce qu'on dit que les plugins-dist peuvent être modifiés directement
par tout le monde comme actuellement ? Et dans ce cas, ils devraient
être placés dans l'organisation Git "spip-zone" ou "friendofspip" (il
faut qu'on finisse de définir les noms).

Ou bien est-ce qu'on considère que les plugins-dist doivent être
surveillés plus étroitement, car il y a une responsabilité de l'équipe
du noyau à ne pas casser la distribution officielle ? Et que donc les
modifications ne devraient être que par des propositions pull request
lorsque c'est pas une personne de l'équipe du noyau. Et donc ces plugins
seraient dans ce cas dans l'organisation Git "spip" tout court.

Lorsqu'on décide qu'un plugin commun doit désormais faire partie des
plugins-dist, ça veut alors dire que l'équipe du noyau décide de
surveiller ce plugin plus fortement, et donc le plugin devrait être
déplacé dans l'autre organisation. Et inversement (finir par passer
"spip/breves" vers "friendofspip/breves").

Hop,

Pour les plugins-dist, ce n'est pas tant un problème technique mais de
choix de gouvernance.

Est-ce qu'on dit que les plugins-dist peuvent être modifiés directement
par tout le monde comme actuellement ? Et dans ce cas, ils devraient
être placés dans l'organisation Git "spip-zone" ou "friendofspip" (il
faut qu'on finisse de définir les noms).

Ou bien est-ce qu'on considère que les plugins-dist doivent être
surveillés plus étroitement, car il y a une responsabilité de l'équipe
du noyau à ne pas casser la distribution officielle ? Et que donc les
modifications ne devraient être que par des propositions pull request
lorsque c'est pas une personne de l'équipe du noyau. Et donc ces plugins
seraient dans ce cas dans l'organisation Git "spip" tout court.

Oui bien sûr ils doivent toujours être accessibles à tou⋅te⋅s, mais ahma uniquement après relecture, donc en mode pull request. Sans ça, on prend le risque d'envoyer un patch foireux ou malveillant dans une release uniquement parce que l'équipe aurait loupé une relecture ou qu'un commit soit "passé sous les radars".

J'ajoute que dans l'idéal ça devrait en être de même pour les commits sur le core, cad passer obligatoirement par pull request et attendre un minium de +1, pouces levés ou autres pour attester de la relecture d'au moins X personnes de l'équipe.

Pour répondre à tonton :

Par contre, je trouve qu'aujourd'hui la séparation entre plugins-dist et
autres plugins sous SVN n'est pas très heureuse. C'est compliqué aussi
quand on décide de passer en plugins-dist un nouveau plugin et la notion de
distribution est toujours en panne.

Si on parle de la distribution SPIP actuelle, on en ajoute pas tous les 3 mois. Et si on parle des distributions alternatives à venir, l'expérimentation de James a bien démontré la simplicité de créer une nouvelle distrib, cf l'exemple de geodiversité.

Yep, je suis d'accord avec toi sur ces deux points.

Et donc à priori on partirait plutôt sur les plugins-dist bien dans
l'organisation "spip" tout court, celle de l'équipe du noyau, comme le core.

Hello,

J’ajoute que dans l’idéal ça devrait en être de même pour les commits
sur le core, cad passer obligatoirement par pull request et attendre un
minium de +1, pouces levés ou autres pour attester de la relecture d’au
moins X personnes de l’équipe.

Yep, je suis d’accord avec toi sur ces deux points.

Et donc à priori on partirait plutôt sur les plugins-dist bien dans
l’organisation “spip” tout court, celle de l’équipe du noyau, comme le core.

Ok.
Donc finalement il n’y a pas de souci majeur à faire cette première étape Core+plugins-dist pour les gens qui utilisent la distribution standard actuelle. Le seul truc qui va se passer si on ne fait pas un traitement spécial (je sais pas lequel d’ailleurs) c’est que les plugins-dist vont disparaitre de Plugins SPIP. Vous me direz vu que ce sont les moins documentés…

Par contre, est-ce qu’on pourrait pas avant de faire le saut “revoir” la liste des plugins-dist en :

  • ajoutant enfin crayons qui doit être installés sur la plupart des sites en choisissant clairement quelle branche on utilise finalement (suite au débat qui a eu lieu il y a quelques mois)
  • Arrêter de trimballer une mini lib YAML dans textwheel alors qu’on a un plugin YAML aujourd’hui bien plus performant (et qui importe des lib composer) et que j’ai proposé une version de Textwheel en JSON qui éviterait même de nécessiter une quelconque librairie (il reste quelques bugs de traduction YAML->JSON à corriger).
  • peut-être autre chose ?

Ca donnerait un caractère moins austère je trouve à cette étape très techno et je ne pense pas que ça reculerais de beaucoup la mise en oeuvre de cette étape…

Qu’en pensez-vous ?

Ou bien est-ce qu'on considère que les plugins-dist doivent être
surveillés plus étroitement, car il y a une responsabilité de l'équipe
du noyau à ne pas casser la distribution officielle ? Et que donc les
modifications ne devraient être que par des propositions pull request
lorsque c'est pas une personne de l'équipe du noyau. Et donc ces plugins
seraient dans ce cas dans l'organisation Git "spip" tout court.

Oui bien sûr ils doivent toujours être accessibles à tou⋅te⋅s, mais ahma
uniquement après relecture, donc en mode pull request. Sans ça, on prend
le risque d'envoyer un patch foireux ou malveillant dans une release
uniquement parce que l'équipe aurait loupé une relecture ou qu'un commit
soit "passé sous les radars".

Ok pour moi sur ce point:
- ça me semble quasi-obligatoire si on ne veut pas finir par se
retrouver avec une "saleté" dans les plugins majeurs (qu'elle ait été
commité intentionnellement ou non)
- et le passage en pull-request/merge-request sur le core et ces
plugins me semble aussi une bonne manière de commencer à profiter des
avantages de l'intégration de git pour le core :slight_smile:

Et donc à priori on partirait plutôt sur les plugins-dist bien dans
l'organisation "spip" tout court, celle de l'équipe du noyau, comme le
core.

OK aussi donc!

et Eric Lupinacci a répondu:

Par contre, est-ce qu'on pourrait pas avant de faire le saut "revoir" la
liste des plugins-dist en :
- ajoutant enfin crayons qui doit être installés sur la plupart des sites
en choisissant clairement quelle branche on utilise finalement (suite au
débat qui a eu lieu il y a quelques mois)
- Arrêter de trimballer une mini lib YAML dans textwheel alors qu'on a un
plugin YAML aujourd'hui bien plus performant (et qui importe des lib
composer) et que j'ai proposé une version de Textwheel en JSON qui
éviterait même de nécessiter une quelconque librairie (il reste quelques
bugs de traduction YAML->JSON à corriger)

à première vue ces 2 propositions me semblent une bonne idée

- peut-être autre chose ?

(ne chargeons pas trop la barque si on veut que ça puisse se faire sans
trop de délais...)

Ca donnerait un caractère moins austère je trouve à cette étape très techno
et je ne pense pas que ça reculerais de beaucoup la mise en oeuvre de cette
étape...

et ça permettrait aussi de faire une version "consistante" pour le
passage à Git

cy_altern

- les traductions vers Git

Juste pour le noter quelque part :

https://stackoverflow.com/questions/2481171/anyone-knows-of-an-opensource-collaborative-translation-app

Bien maintenu, en python, liable à de l'intégration continue avec des
hooks :
https://weblate.org/fr/
https://github.com/WeblateOrg/weblate

Ce qui ne veut pas dire qu'on ne doit pas réfléchir à modifier
trad.spip/salvatore pour lui faire pusher en Git au lieu de SVN hein,
surtout si c'est moins long.

Mais je note ça quand même, car m'est-avis qu'à terme, tout comme pour
les projets tiers en PHP, ça nous allégerait beaucoup de boulot de ne
pas avoir à maintenir une grosse fonctionnalité compliquée quand il
existe des logiciels bien libres qui le font, maintenus par beaucoup
plus de gens que nous.

Hop,

Et bé oui, bien sûr ! Tutti bene !

Salut

Pour info le svn>git fonctionne déjà actuellement. On peut maintenir
les droits SVN aux bots le temps que le code soit migré en git pur.

Km

A propos du repo git :

J'ai voulu faire un PR sur le repo GIT du core
mais bien que pratiquant git à ma mesure depuis quelques années,
je n'avais encore jamais fait ça, et je n'y suis pas parvenu.

Ce serait bien d'élaborer une documentation sur la manières de travailler avec git
plus aboutie de celle qui existait (ou pas, selon le niveau d'exigence) pour SVN.

Idem pour composer quand yaura matière à.

Pour info, j'ai aussi essayé de le faire par l'UI du gitea,
et je n'y suis pas parvenu (mais j'ai pas insisté).
C'est possible ?

Par contre, j'ai réussi à le faire par l'UI de github.

JLuc

Bonjour

On peut faire des PR depuis git.spip.net mais avec les indications
communiquées il m'est impossible de comprendre ce qui ne fonctionne
pas et/ou pourquoi et donc donner une aide quelconque.

Km

On peut faire des PR depuis git.spip.net mais avec les indications
communiquées il m'est impossible de comprendre ce qui ne fonctionne
pas et/ou pourquoi et donc donner une aide quelconque.

Voici plus en détail dans les différents cas de figure.

A propos du repo git :

J'ai voulu faire un PR sur le repo GIT du core
mais bien que pratiquant git à ma mesure depuis quelques années,
je n'avais encore jamais fait ça, et je n'y suis pas parvenu.

Localement j'ai fait
git clone https://git.spip.net/SPIP/spip.git
Là j'ai appliqué ma modif.
Je n'ai pas su comment pull request ensuite.
Quelle serait la commande ?

Pour info, j'ai aussi essayé de le faire par l'UI du gitea,
et je n'y suis pas parvenu (mais j'ai pas insisté).
C'est possible ?

J'avais créé un clone sur git.spip il y a 2 mois
https://git.spip.net/JLuc/spip
Je ne parviens pas à le mettre à jour via l'UI fournie.
Ya moyen ?

Par contre, j'ai réussi à le faire par l'UI de github.

En effet le bouton qui permet les merge est "inversible" :
on peut merger du clone vers l'origine (pour faire une PR)
mais aussi de l'origine vers le clone (pour synchroniser = rattraper les commits en retard)

JLuc

J’avais écrit un processus de travail pour git dans mon ancienne boite ; quelque chose de simple mais suffisamment détaillé. Nous étions sur le modèle d’yne branche master toujours propre, avec système de PR depuis les clones sur Github.

Est-ce que vous seriez intéressez ?

mais oui bien sûr! :slight_smile:

Peut être que le mieux serait d'en faire un article sur contrib?
Un peu comme ceux qu'on trouve dans la rubrique sur l'utilisation de SVN
(https://contrib.spip.net/Utiliser-SVN-SPIP-ZONE)

Merci d'avance ...

cy_altern

Bonjour…

J’ai traduit le document dont je parlais vers le français en faisant les adaptations que je pensais nécessaires pour Spip. J’ai posé un export HTML sur mon serveur pour l’instant (originaire d’un markdown).

Dites‑moi s’il est utile et serait mieux ailleurs ; je ne sais jamais bien où m’orienter avec la documentation spip. Merci. :slight_smile:

Bonne journée !

Bonjour

> On peut faire des PR depuis git.spip.net mais avec les indications
> communiquées il m'est impossible de comprendre ce qui ne fonctionne
> pas et/ou pourquoi et donc donner une aide quelconque.

Voici plus en détail dans les différents cas de figure.

>> A propos du repo git :
>>
>> J'ai voulu faire un PR sur le repo GIT du core
>> mais bien que pratiquant git à ma mesure depuis quelques années,
>> je n'avais encore jamais fait ça, et je n'y suis pas parvenu.

Localement j'ai fait
git clone https://git.spip.net/SPIP/spip.git
Là j'ai appliqué ma modif.
Je n'ai pas su comment pull request ensuite.
Quelle serait la commande ?

Tu ne peux pas tu n'as pas les droits. Le principe d'une PR c'est de
proposer une branche à appliquer sur une autre (sur le même dépot ou
non).
SPIP/spip.git n'est pas disponible à l'écriture. Donc il n'est pas
possible de créer une branche, ce qui signifie qu'il n'est pas
possible de faire une PR.

Seules les personnes ayant des droits d'écriture sur ce dépôt
pourraient faire un PR. Mais en mon sens cela serait une très mauvaise
pratique.

>> Pour info, j'ai aussi essayé de le faire par l'UI du gitea,
>> et je n'y suis pas parvenu (mais j'ai pas insisté).
>> C'est possible ?
J'avais créé un clone sur git.spip il y a 2 mois
https://git.spip.net/JLuc/spip
Je ne parviens pas à le mettre à jour via l'UI fournie.
Ya moyen ?

Mettre à jour le dépot pas à ma conaissance. Faire une PR oui

Une fois sur ton fork/bifurcation.
Tu navigues dans la branche et le fichier qui t'intéresse. Par exemple
la branche master et le fichier spip.php

Tu verras un crayon sur le coté du fichier :
https://framapic.org/U6bzHLHsUGB6/XqL1p68dTJ9i.png

Si tu cliques dessus tu peux éditer en ligne le fichier et créer une
nouvelle branche (cf plus haut un PR c'est une branche)
https://framapic.org/AzzIteo0QmSY/l3HvD9MEC4kk.png

Ensuite tu vas sur "Demandes d'ajout", nouvelle demande
https://framapic.org/xREEahib9VCV/7BXz9kNuC63q.png

Et enfin tu précise sur quelle branche tu veux voir appliquer ton
correctif (autrement dit la PR)
https://framapic.org/XghNg3jxgYLS/GgA2xUQuw7Vy.png

Ce qui donnera
https://git.spip.net/SPIP/spip/pulls/8

Mais c'est pour moi une mauvaise pratique de vouloir à tout pris
passer par l'interface graphique. Cela n'a de vrai sens que si on
constate une modification restreinte et évidente.
Si on doit modifier plusieurs fichiers ou raisonner en plusieurs
commit il es préférable de passer par un vrai clone local de son fork.
Lorsqu'on pousse ensuite sa branche sur le dépot, gitea fournit en
réponse un lien pour créer la PR au besoin. (cf mail concernant
comment faire un PR)

>> Par contre, j'ai réussi à le faire par l'UI de github.
En effet le bouton qui permet les merge est "inversible" :
on peut merger du clone vers l'origine (pour faire une PR)

cf dessus.

mais aussi de l'origine vers le clone (pour synchroniser = rattraper les commits en retard)

Tiens ça c'est une nouveauté jusqu'à peu github ne proposait pas la
mise jour graphique de l'upstream.
Pas possible encore dans gitea à ma connaissance.

En espérant avoir été clair.

Km

PS il serait bien de centraliser tout ça car, il me semble que c'est
le 3eme ou 4eme fil de discussion ouvert sur la même question.

Actuellement ya cette page du wiki FAQ pratique : Comment SPIPer avec git.spip.net qui tente de rassembler les questions pratiques relatives au gitea en place.