[spip-dev] [SPIPremix] Une distribution SPIP alternative

Dev
21

Encore un témoignage, dans le texte.

Un autre fait est qu'on ne sait pas quelle proportion d'utilisateurs déploient du SPIP avec "spip_loader" ou par "téléchargement manuel de zip+ftp" ou "svn local+ftp" ou "ssh+svn" ou "apt sur debian" ou "ssh+spip-cli" ou "yunohost" ... ou tout autre combinaison, en fonction des besoins, de ce que permet l'espace privé, de l'hébergeur et de ce qui est requis pour des plugins ou des "libs" à "installer".

Faut-il faire un sondage chez les Spipeurs pour avoir une idée de ces statistiques?

En ce qui me concerne, je gère ou ai créé/géré essentiellement des sites associatifs et quelques sites perso à usage privé, tout ça bénévolement bien sûr. Rien de très ambitieux là-dedans. Mon profil: connaissances générales en informatique, mon poste de travail est sous Linux (Ubuntu) et je sais bosser en ligne de commande. Je peux programmer en php mais pas assez souvent pour que tout me vienne automatiquement, et j'ai franchement du mal avec le SQL.

Pour des raisons économiques évidentes, je ne travaille qu'avec des hébergements gratuits (Free) ou à petit tarif (OVH). La contrepartie, ce sont des limitations fortes:
- chez Free, on ne peut faire que de l'upload (fichier par fichier) ou du FTP. Pas de SFTP, pas de connexions externes possibles depuis le serveur et encore moins d'accès SSH ou SVN. Mais c'est gratuit et sans pub;
- chez OVH-perso (50€/an à la louche), pas de SSH, pas de SVN (enfin je n'ai pas creusé la question) mais au moins on a un accès SFTP et on peut utiliser spip_loader.

Bref, tout ça pour dire que si le seul argument pour demander à la communauté de maintenir spip_loader, c'est qu'on pourrait perdre des utilisateurs, je le considère comme irrecevable tant qu'on ne m'aura pas apporter la preuve que c'est ce dont les utilisateurs encore les plus actifs sont le plus dépendants.

Je ne vois pas comment on pourrait en apporter une "preuve" quelconque. Par contre une chose est sûre: pouvoir utiliser spip_loader, c'est un vrai bonheur. C'est simple (surtout la dernière version parue) et ça fonctionne dans se poser de questions. Tout comme SVP pour les plugins. On ne remerciera jamais assez les devs pour ce super boulot.

N'avoir que du (S)FTP ça devient vite lourdingue quand on veut se tenir à jour. Il faut aller voir sur Contrib ou la zone si les plugins n'ont pas été mis à jour, charger les zip en local, les désarchiver et tout renvoyer sur le serveur... Pour la dist on est prévenu des mises à jour par la liste mais là aussi il faut tout déziper en local et effacer la dist précédente du serveur avant de tout recharger. C'est le "prix" à payer pour un hébergement gratuit.

Je rêve de pouvoir juste envoyer un zip sur le serveur et que celui-ci se débrouille pour tout installer (y compris la création des répertoires vides, comme l'ont signalé d'autres intervenants).

J'ajoute aussi que je ne connais pas beaucoup d'hébergeurs qui fournissent un accès à leurs machines avec (s)ftp comme seule méthode de déploiement.

Ce n'est pas tant une question d'hébergeur que de type d'hébergement. Si tu regardes les mutu premiers prix, il est rare que tu bénéficies d'un accès SSH.

Christian

22

Bonjour,

23

J’ai plus d’une 30aine de site de fait au Quebec sous SPIP…

Je me sers uniquement de Spip_loader pour les installation et mise-a-jour de mes Spip…

24

Bonsoir,

[...]

Donc ne changer rien et ce qui est a la mode aujourd'hui passera demain.

Bon OK ;
On ne change rien ; ça on sait déjà bien faire :slight_smile:

Les dernières versions du loader sont visiblement bien appréciées (auto-congratulons-nous). Je vous rappelle que son code est sur la zone si vous voulez qu’il crée les répertoires plugins/auto, lib, squelettes manquants…). Y a pas d’obstruction…

Ceci étant dit, deux points :

1) sur la mode.

Je pense que non, cela n’a rien d’une mode ! Désolé ; la communauté PHP a mis un temps fou à s’organiser pour trouver une solution acceptable et acceptée d’organisation des librairies partagées pour dire «tatata, c’est une mode» …

Tu n’as pas un seul nouveau projet qui se dirait : tiens nous on va faire du code pas objet, sans réutiliser de librairies packagées, sans utiliser Composer, sans suivre quelques suggestions PSR.

L’histoire personnelle de SPIP est comme cela, certes, mais faut-il continuer ?

Je vais tenter de faire une relation avec les plugins de SPIP. En tant qu’utilisateurices, on est content·e·s de voir des supers plugins naître ou évoluer.

Savez-vous que régulièrement, un plugin va utiliser, en sous-jacent, des librairies php existantes. Figurez-vous qu’actuellement on est profondément embêtés quand on veut utiliser une librairie récente de la communauté PHP : celle-ci déclare quelques fichiers à elle, et ses dépendances (à d’autres librairies), comme le feraient nos propres plugins. Du coup comment intègre t-on cette librairie dans notre plugin ? on copiant la lib + toutes ses dépendances. Qui sont probablement les mêmes que les dépendances d’un autre plugin SPIP intégrant une autre librairie… On se retrouve avec possiblement plein de fichiers en doubles, de multiples autoloaders à éventuellement charger, du code dupliqué, des mises à jour compliquées.

Quelques exemples dans la zone :

25

(...) Je vous rappelle que son code est sur la zone si vous voulez qu’il crée les répertoires plugins/auto, lib, squelettes manquants…). Y a pas d’obstruction…

J'avais compris que la création des dossiers dépendait de SPIP (quelque soit son mode d'installation) et non pas de spip_loader ?
(par ailleurs il serait difficile d'imaginer le répertoire plugins/auto créé lors d'une installation via spip_loader et pas d'une autre manière)
Mais je me trompe peut-être ?

Jacques

26

Oui et non. Le spip-loader déballe le fichier zip qui contient les fichiers de SPIP. Ce zip là n’a pas de répertoire plugins, lib ou squelettes (ce n’est pas nécessaire à SPIP directement, ils ne sont pas dans le dépot svn).

Mais le spip-loader est un script qui fait différentes actions (pas que déballer et copier ce zip). Il pourrait faire des actions en plus… comme tester si certains répertoires sont présents ou non et les créer le cas échant.

MM.

27

Salut

Je sors ma casquette d'hébergeur. Sur l'ensemble des sites/serveurs
que j'héberge je n'ai eu qu'une seule demande pour avoir un accès
ssh/composer. Et c'est un cas particulier car c'est une agence web qui
développe des sites avec une machine dédiée pour ceci.

Dans tous les autres cas hébergés, c'est du (s)ftp(s) et usage des
méthodes web pour installer les modules du cms utilisés. Et il ne
seront ni prêt à payer une prestation pour qu'une personne s'occupe
d'installer les modules (perte d'autonomie et de maîtrise) et ni prêt
à se former à ssh/composer (on ne peut pas tout maîtriser). Dans ce
cas ce sera un changement de crémerie.

Composer est une bonne solution pour gérer des dépendance et il est
inutile de réinventer la roue quand celle ci existe et n'est pas
carrée (la roue). Une des forces de SPIP c'est de ne pas être orienté
développement php, ce qui est tout le contraire de composer. Il semble
utile d'avoir un compromis et cela ne me semble pas incompatible.

Km

28

Salut

Salut,

Je sors ma casquette d'hébergeur. Sur l'ensemble des sites/serveurs
que j'héberge je n'ai eu qu'une seule demande pour avoir un accès
ssh/composer. Et c'est un cas particulier car c'est une agence web qui
développe des sites avec une machine dédiée pour ceci.

Dans tous les autres cas hébergés, c'est du (s)ftp(s) et usage des
méthodes web pour installer les modules du cms utilisés. Et il ne
seront ni prêt à payer une prestation pour qu'une personne s'occupe
d'installer les modules (perte d'autonomie et de maîtrise) et ni prêt
à se former à ssh/composer (on ne peut pas tout maîtriser). Dans ce
cas ce sera un changement de crémerie.

Merci pour ce retour.

Peut-on savoir quels cms sont utilisés sur tes plates-formes et parmi eux,
lesquels, si c'est pas SPIP, offrent aussi une méthode web, stp ?
Cela permettrait d'aller les étudier et de faire des comparaisons. On a
peut-être là l'occasion d'améliorer spip_loader si nécessaire.

Composer est une bonne solution pour gérer des dépendance et il est
inutile de réinventer la roue quand celle ci existe et n'est pas
carrée (la roue). Une des forces de SPIP c'est de ne pas être orienté
développement php, ce qui est tout le contraire de composer. Il semble
utile d'avoir un compromis et cela ne me semble pas incompatible.

Pour dissiper un malentendu, je me permets une petite précision :

composer n'oriente pas sur la technologie de développement. C'est, comme tu
l'indiques un gestionnaire de dépendances, pas un framework de
développement alors que SPIP pourrait être considéré comme tel. C'est
difficilement comparable. Donc a fortiori opposable.
Certes, composer est écrit en PHP, comme SPIP. Mais l'objet de la démo
SPIPRemix était bien de démontrer qu'il permet de gérer les dépendances de
SPIP, a priori pas orienté PHP.

Et ça marche : spip/dist est un squelette essentiellement basé sur html,
spip/prive aussi. Le squelettes de geodiv dans la distribution alternative
aussi. toujours dans geodiv, on peut s'apercevoir, si on regarde de près,
que certains plugins servent à distribuer des librairies javascript. Etc.

Ce qui oriente sur la technologie, et accessoirement les méthodes de
conception php différentes de ce qu'on fait dans SPIP aujourd'hui, ce sont
les PSR. Il y a déjà eu une discussion sur spip-dev à ce sujet et il est
vrai que Matthieu, entre autres, a très envie qu'on s'y intéresse.
J'avais pris la précaution de bien distinguer les deux choses (composer
d'un coté et PSR de l'autre) en arrêtant la démonstration à la seule
gestion de dépendances. Si cette solution est adoptée, il deviendrait
beaucoup plus facile de s'intéresser aux bénéfices que les PSRs
apporteraient à SPIP.

Le fait que SPIPRemix fait cohabiter des fichiers composer.json et
paquet.xml me semble prouver que le compromis est déjà trouvé, même s'il a
des cotés frustrants pour l'instant.
Je le rappelle, c'était la limite de la maquette. La suite demande qu'on
modifie du code.

Km

Amicalement,

29

Encore un témoignage, dans le texte.

Merci. :slight_smile:

Un autre fait est qu'on ne sait pas quelle proportion d'utilisateurs
déploient du SPIP avec "spip_loader" ou par "téléchargement manuel de
zip+ftp" ou "svn local+ftp" ou "ssh+svn" ou "apt sur debian" ou
"ssh+spip-cli" ou "yunohost" ... ou tout autre combinaison, en fonction des
besoins, de ce que permet l'espace privé, de l'hébergeur et de ce qui est
requis pour des plugins ou des "libs" à "installer".

Faut-il faire un sondage chez les Spipeurs pour avoir une idée de ces
statistiques?

à défaut de statistiques de téléchargements des zip regroupés par
User-Agent et d'usage de svn, pourquoi pas ?

Amicalement,

30

Salut

Je sors ma casquette d'hébergeur. Sur l'ensemble des sites/serveurs
que j'héberge je n'ai eu qu'une seule demande pour avoir un accès
ssh/composer. Et c'est un cas particulier car c'est une agence web qui
développe des sites avec une machine dédiée pour ceci.

Dans tous les autres cas hébergés, c'est du (s)ftp(s) et usage des
méthodes web pour installer les modules du cms utilisés. Et il ne
seront ni prêt à payer une prestation pour qu'une personne s'occupe
d'installer les modules (perte d'autonomie et de maîtrise) et ni prêt
à se former à ssh/composer (on ne peut pas tout maîtriser). Dans ce
cas ce sera un changement de crémerie.

Merci pour ce retour.

Peut-on savoir quels cms sont utilisés sur tes plates-formes et parmi eux,
lesquels, si c'est pas SPIP, offrent aussi une méthode web, stp ?
Cela permettrait d'aller les étudier et de faire des comparaisons. On a
peut-être là l'occasion d'améliorer spip_loader si nécessaire.

Pour les cas hébergés wordpress, spip et Prestashop. 3 solutions qui
actuellement proposent une interface pour gérer tant les extensions
que les mise à jour. Plus du php/html legacy/maison.

Pour le cas avec composer, c'est suite à une installation Thelia.
Sachant que l'ecommerçant ne maitrise rien, c'est l'agence qui bose.
Pour les autres cas ce sont des dev maisons de l'agence qui pousse
ensuite via ftp sur l'hébergement concerné.

Composer est une bonne solution pour gérer des dépendance et il est
inutile de réinventer la roue quand celle ci existe et n'est pas
carrée (la roue). Une des forces de SPIP c'est de ne pas être orienté
développement php, ce qui est tout le contraire de composer. Il semble
utile d'avoir un compromis et cela ne me semble pas incompatible.

Pour dissiper un malentendu, je me permets une petite précision :

composer n'oriente pas sur la technologie de développement.
C'est, comme tu
l'indiques un gestionnaire de dépendances, pas un framework de développement
alors que SPIP pourrait être considéré comme tel.

Il n'oriente pas sur la technologie c'est technologique. Je reformule
donc ma remarque initiale en enlevant PHP de ma phrase.
Composer est un truc de développeur pour développeur (quelque soit son langage).

Et encore parmi les personnes qui développe que je côtoie, parler de
ligne de commande c'est parfois compliqué.

C'est difficilement
comparable. Donc a fortiori opposable.

Maîtriser ssh et la ligne de commande n'est pas équivalent à utiliser
une interface web.A mon sens ce n'est pas pas opposable et l'un ne
remplace pas l'autre. Les publics et usages sont différents et se
croisent.

Certes, composer est écrit en PHP, comme SPIP. Mais l'objet de la démo
SPIPRemix était bien de démontrer qu'il permet de gérer les dépendances de
SPIP, a priori pas orienté PHP.
Et ça marche : spip/dist est un squelette essentiellement basé sur html,
spip/prive aussi. Le squelettes de geodiv dans la distribution alternative
aussi. toujours dans geodiv, on peut s'apercevoir, si on regarde de près,
que certains plugins servent à distribuer des librairies javascript. Etc.

Ma remarque n'avait rien à voir avec ce point. Désolé si on s'est mal compris.

Ce qui oriente sur la technologie, et accessoirement les méthodes de
conception php différentes de ce qu'on fait dans SPIP aujourd'hui, ce sont
les PSR. Il y a déjà eu une discussion sur spip-dev à ce sujet et il est
vrai que Matthieu, entre autres, a très envie qu'on s'y intéresse.
J'avais pris la précaution de bien distinguer les deux choses (composer d'un
coté et PSR de l'autre) en arrêtant la démonstration à la seule gestion de
dépendances. Si cette solution est adoptée, il deviendrait beaucoup plus
facile de s'intéresser aux bénéfices que les PSRs apporteraient à SPIP.

Pas rapport à la remarque initiale, cela me semble hors sujet. En tant
qu'hébergeur le choix du développement (psr ou autre) n'a aucune sorte
d'importance.

Le fait que SPIPRemix fait cohabiter des fichiers composer.json et
paquet.xml me semble prouver que le compromis est déjà trouvé, même s'il a
des cotés frustrants pour l'instant.
Je le rappelle, c'était la limite de la maquette. La suite demande qu'on
modifie du code.

Oui c'est là où ça coince car la maquette montre qu'on peut utiliser
composer comme gestionnaire de dépendance mais ne remplace pas le
gestionnaire actuel qu'est SVP.
Au vu de l'objectif et du fonctionnement pour la partie spip_loader on
peut contourner le problème vu qu'on fournit une archive à installer.

L'utilisabilité de la chose est aussi importante que la faisabilité
(ce qui est démontré)

Km

31

Méthode web d'installation non.

Mais mise à jour de l'appli elle même depuis son propre back office oui.

Ce que ne fait toujours pas SPIP au passage (tu n'as pas envisagé ça comme cause des retards de mise à jour ?).

Et installation / mise à jour de [modules|plugins|extensions], toujours depuis le back office, oui aussi.

32

cam.lafit@azerttyu.net a écrit le 05/07/2018 à 16:41 :

Maîtriser ssh et la ligne de commande n'est pas équivalent à utiliser
une interface web.A mon sens ce n'est pas pas opposable et l'un ne
remplace pas l'autre. Les publics et usages sont différents et se
croisent.

Pour des réfractaires de SSH + svn up
j'ai été amené à écrire un .php qui lance les commandes shell qui vont bien (je peux le partager si besoin).

Donc, il est possible de fournir des commandes shell via une interface web.
C'est pas idéal.
Et en cas modification des branches, c'est même merdique.

Et c'est là que j'ai l'impression que Composer changerait la donne.

Mes 2 sous

33

Salut,

dans ce que tu présentes là il y aurait une bascule totale sur Composer/Packagist, de SPIP (core + dist) et des plugins de la zone.
Ça me semble très utopiste, à minima vu le peu d'enthousiasme (euphémisme) sur le travail de James.

Je reviens un peu sur l'origine des discussions.

Il était question à la base de basculer le core et les plugins dist sur Git, ce qui a été acté depuis longtemps (plusieurs années).
Puis depuis ce début d'année d'une nouvelle méthode de gestion des paquets / dépendances et de distribution de SPIP par Composer.
Je suis à 200% pour.

Mais il n'a pas été dit ni discuté que la zone entière basculait aussi sur Git, et encore moins sur Composer.

Et si c'était décidé/acté, ce serait

Soyons réaliste, il me semble évident que pendant un certain temps, on va continuer à devoir maintenir smart_paquets et les archivelist, et gérer l'installation des plugins comme elle est aujourd'hui.

34

Nicod a écrit :
« dans ce que tu présentes là il y aurait une bascule totale sur Composer/Packagist, de SPIP (core + dist) et des plugins de la zone.
Ça me semble très utopiste, à minima vu le peu d'enthousiasme (euphémisme) sur le travail de James. »

l'enthousiasme se commande pas...
et c'est un gros changement donc il peut y avoir de grosses résistances

Là en plus, le changement est excluant :
certains usagers historiques de spip ne pourront pas installer/mettre/utiliser (selon le contour de l'évolution) une nouvelle version avec composer.

De plus, les prérequis pour cette future version sont encore mal connus
ce qui est plus inquiétant que si les prérequis étaient bien cernés.
Les futurs potentiels exclus ne peuvent pas voir le changement avec enthousiasme !

Les docs de James, qui documentent la technique, sont muettes sur ces dimensions
ou alors c'est difficile à trouver ou à comprendre :
- Faudra-t-il/faudrait-il une console ssh ?
- D'autres pré requis techniques ?
- Puisque Composer est gourmand, quelle puissance serveur faut il ?
- Ça marchera t y sur un mutu de base ? Quels hébergements cela exclue t il ?
- Quels savoirs sont ils requis pour l'utiliser ? Comment les acquérir ?

C'est aussi à l'aune de ces questions que les évolutions envisagées doivent être appréciées.

(et il me semble, ça tombe bien, qu'une partie des discussions actuelles vise justement à limiter l'exclusion)

Ça faisait partie de la vocation de SPIP d'être inclusif :
un moyen pour des noobs de devenir webmestre et découvrir la publication web.
ç'a été un des moteurs idéologiques pour sa création,
mais pas l'unique moteur : yavait aussi, par exemple, le simple plaisir des devs,
et la tendresse (et l'humour certainement !).

C'est cela qui fait avancer spip.

Yavait aussi, dès le début, 1 autre moteur : l'économique.
Dev avec spip est un gagne pain pour certains devs du core ou de plugins
séduits par l'esprit spip et par les possibilités de l'outil.
C'est souvent eux qui produisent les plugins les plus performants,
qui introduisent les nouveaux paradigmes,
et qui ouvrent les passerelles les plus audacieuses avec d'autres univers logiciels.

Si aujourd'hui SPIP est en manque d'énergie en son statuquo actuel
pour se propulser vers le XXIIeme siècle,
ce ne serait pas forcément une trahison que d'être réaliste
et redéfinir les objectifs et la vocation.

Passer à Composer, c'est s'appuyer sur l'énergie des devs,
et l'espoir qu'en se modernisant, spip puisse plus facilement s'ouvrir à d'autres univers
et à d'autres contributeurs.
Si c'est le chemin, ce qui reste à voir car effectivement peu de devs se sont prononcés,
essayons de faire en sorte que ça soit respectueux de tous.

Il me semble que des réponses aux questions plus haut y contribuera.

JL

35

Tiens je profite de l’appel du pied…
Je suis totalement à la ramasse sur le sujet Composer faute de temps, mais je suis totalement pour le fait d’utiliser cet outil commun à tout l’univers PHP, et je suis bien content que James ait eu l’énergie de s’y coller et de faire cette maquette.

Pour autant il faut en effet surement veiller à ne pas sabrer comme ça d’un coup la possibilité d’avoir un installeur web comme spip_loader, car je sens que c’est un outil largement utilisé par les utilisateurs SPIP.
Mais ça n’est sans doute pas le plus compliqué à maintenir dans la mesure où rien ne nous empêche de continuer à préparer un zip prêt à l’install à partir d’un serveur qui compose.

Ce qui m’inquiète plus c’est la dichotomie Composer/SVP. Si maintenir 2 méthodes de mises à jour/téléchargement/installation de plugins/composant me parait dispendieux, je ne pense pas qu’on puisse sérieusement dire « maintenant tout devra se faire en ligne de commande avec composer ». Ça marche bien pour des devs dans les frameworks, applis etc, ce n’est pas viable pour de simples utilisateurs/webmestre de SPIP.
Il faut donc qu’on trouve collectivement une solution maline à ce problème, ce dont je ne doute pas !

36

Salut

En faisant des recherches pour voir comment avancer sur la lancée je
suis tombé sur : https://www.ostraining.com/blog/coding/composer-cms/

Je constate qu'on n'est pas les premiers à se poser la question. Ce
qui est plutôt bon signe. Le problème c'est que je n'ai pas vu de
solutions. Il faut continuer à creuser, on va bien trouver une
solution.

Km

37

Soyons factuels, trouver une solution à quel problème ?

Il y a pas mal de confusion dans certains échanges, il ne faut pas tout mélanger sinon on n'avancera pas.

Pour recentrer un peu :

La maquette produite par James est un POC, une démonstration qu'on peut gérer le core + plugins dist avec Composer, et créer des distributions (le vieux serpent de mer).
C'est entièrement documenté, et pas que techniquement, c'est même super intéressant pour comprendre toute la démarche : https://spip.lerebooteux.fr/

Il reste le problème des langues et traductions soulevé par James, et probablement des détails à régler, mais ça fonctionne, CQFD, et ça s'arrête là.

Les plugins de la zone ne sont pas concernés, et ne l'ont jamais été.
Pour l'instant on reste donc sur la méthode actuelle (SVN + smart_paquets + SVP).
Ce n'est pas idéal, comme ça a été dit, on doit maintenir deux méthodes parallèlement et ce serait chouette de tout moderniser d'un coup mais c'est un autre chantier.

Il n'a jamais été question non plus de supprimer spip_loader.

Ça a été bien précisé noir sur blanc.
Relisez le paragraphe "Futur immédiat" :
https://spip.lerebooteux.fr/L-installeur-Composer-pour-SPIP

38

L'article est assez juste si on lit bien son titre, "5 Reasons Not to Require Composer" : require au sens de rendre obligatoire.

Un passage à Composer selon la méthode proposée par James ne le rendrait pas plus obligatoire (côté serveur comme en local) que ne l'est SVN actuellement.

On pourra très bien, faire un `composer create-project` ou bien continuer à tout installer à la mano depuis un ZIP.

Et si on [ne veut pas|ne sait pas|ne peut pas] utiliser Composer côté serveur, on peut toujours déployer en ligne par une autre méthode (sFTP, Webdav, gitftp...)
NB : Composer est un outil de gestion de dépendances, pas un outil de déploiement.

Ce n'est pas la mort des "petits hébergements" qui a été annoncée, ni la mise à l'écart de celleux qui ne savent pas / ne veulent pas passer à Composer.

En fait, sur les 5 points de l'article, le seul qui nous pose une bonne question est le #2 (accès bloqué à Github/Packagist).

Si c'est vraiment un frein, on peut héberger notre propre Satis :
https://composer-spip.lerebooteux.fr/

39

Hop,

Merci pour ce mail, il contient presque tout ce que je comptais envoyer.

Amha, si on se lance dans ce chantier de manière coordonnées, comme une équipe quoi, ça ne devrait pas poser de pb :slight_smile:
‎
Et comme on semble être bien motivé⋅e⋅s en groupe, c'est l'occasion d'en profiter.

Quelques ajouts/remarques :

Pour recentrer un peu :

La maquette produite par James est un POC, une démonstration qu'on peut gérer le core + plugins dist avec Composer, et créer des distributions (le vieux serpent de mer).

Oui, cela permettrait de régler ce fameux truc qu'on traîne depuis perpète, et plein d'autres choses, exemple :

À ce jour on a un bug dans spip_loader du fait qu'il ne contient pas une version à jour de recuperer_page() cf le ticket https://core.spip.net/issues/4113 (alors que le bug en question est corrigé dans SPIP).

Avec composer, on pourrait extraire certaines fonctions/librairies du core sous forme de composants afin de les rendre "automatiquement" disponible à d'autres projets comme spip_loader (ou autres). Cela faciliterait grandement le travail de maintenance des nos outils, et nous permettrait d'éviter le genre de situation du bug cité plus haut.

Autre intérêt, je discutais l'autre jour avec le développeur de YesWiki et lui vantait les mérites de nos supers fonctions d'import de flux RSS. Si celles-ci étaient disponibles sous forme de composant, ce développeur pourrait les utiliser facilement dans son projet, et peut-être même qu'il deviendrait indirectement contributeur à SPIP en contribuant au code du composant en question. Ainsi, le partage et la diffusion de librairies aujourd'hui internes à SPIP pourrait nous permettre de gagner des contributeurs.

C'est entièrement documenté, et pas que techniquement, c'est même super intéressant pour comprendre toute la démarche : https://spip.lerebooteux.fr/

Oui, il y a peut-être beaucoup à lire à première vue, mais pas tant que ça en fait, et tout y est bien annoncé "clairement".

Il reste le problème des langues et traductions soulevé par James, et probablement des détails à régler, mais ça fonctionne, CQFD, et ça s'arrête là.

Oui encore, il reste des choses à faire, mais c'est tout à fait normal puisque le travail de James est une maquette, et je ne doute pas qu'on y arrivera collectivement.

Les plugins de la zone ne sont pas concernés, et ne l'ont jamais été.
Pour l'instant on reste donc sur la méthode actuelle (SVN + smart_paquets + SVP).

+1 (histoire de changer du oui ^^), un SPIP installé par composer peut fonctionner avec SVP.

Il n'a jamais été question non plus de supprimer spip_loader.

Exactement, spip_loader sera toujours disponible, ça serait un peu con de notre part de vouloir s'en débarrasser après toutes les super fonctionnalités qu'on y a ajouté dernièrement (merci encore eux personnes qui ont bossé là dessus).

Pour conclure, on est assez doué⋅e⋅s pour assurer la compat ascendante jusqu'ici, ça nous tient à cœur et ça ne devrait pas changer de ce côté :slight_smile:

zoubis

40

Cerdic a écrit le 10/07/2018 à 09:24 :

Il faut donc qu’on trouve collectivement une solution maline à ce problème, ce dont je ne doute pas !

SVP est déjà capable d'utiliser 2 méthodes de téléchargement :
- par zip
- par SVN (un define à mettre dans mes_options)

Qu'est-ce qui interdirait d'imaginer une 3e méthode qui :
- ferait appel à composer
- via une api de communication avec un serveur distant (pour des questions de performance, il faudrait sans doute un cache du résultat)
- qui renverrait la liste des zip à installer (via la méthode zip)

Mes 2 sous