bootstrap, framework, sdk

Salut,

Après avoir introduit la possibilité d’utiliser composer dans la version de développement de SPIP5, et même s’il reste des travaux à faire dans les plugins-dist compresseur et safehtml (j’y reviendrai dans d’autres topics), nous avons pris le temps de réfléchir, avec @marcimat, à la possibilité de se servir des infos de composer pour gérer les versions et la compatibilité des plugins.

Pour permettre une transition douce, l’idée est de conserver l’existant (paquet.xml, svp) et donc, de ressortir ce vieux sujet d’il y a 2 ans : Et si on rendait les attributs version et etat optionnels dans la balise paquet des fichiers paquet.xml ? : Désormais, cette proposition peut évoluer pour rendre les attributs version, etat et compatibilite optionnelles dans les fichiers paquet.xml afin qu’il soit possible à un SPIP5 de traiter de la manière la plus transparente possible le cas où un plugin, dist ou pas, est « composerisé » ou non. À ce jour, on peut gérer les versions et les états avec composer, reste à traiter le cas de la compatibilité :

Si on refaisait aujourd’hui un recensement des fonctions de SPIP utilisées dans les plugins et qu’on poussait l’analyse plus loin que ce que j’avais fait à l’époque, il serait possible d’isoler une partie de ces fonctions dans (au moins) un nouveau package composer pour SPIP.

Supposons qu’on l’appelle spip/framework et qu’on sorte une version (stable) 5.0.0 et qu’il permette d’utiliser au moins une fonction très pratique include_spip() (ce n’est qu’un exemple, c’est un exercice de pensée). Il deviendrait alors assez simple d’ajouter ce package comme dépendance dans SPIP lui-même pour commencer : SPIP serait « compatible » avec le « framework » version 5, parce qu’il peut utiliser la fonction include_spip(). On ajoute cette même dépendance dans le plugin dist spip/bigup et ce dernier devient « compatible » avec le « framework » version 5, lui aussi. Bien sûr, un tel package pourra prendre en charge d’autres fonctions. C’est là tout le coté un peu « fastidieux » du chantier.

La gestion des plugins de SPIP devra dans ce cas lire les données techniques produites par composer pour afficher et traiter les infos de version dans l’admin en plus des données présentes dans les paquet.xml.

  • On pourrait alors enlever les attributs concernées dans spip/bigup puisque ce serait les infos composer qui serviraient alors.
  • Un plugin non-composerisé continuera d’indiquer ses infos dans son fichier paquet.xml avec les attributs historiques.

Je vais pousser du code expérimental dans une branche de spip et créer un nouveau dépôt git ce week-end et poursuivre les explications dans ce thread au fur et à mesure.

2 « J'aime »

Super, merci pour les news du chantier, gogogo !

J’ai tout compris ! Merci… sauf « le titre ».

Boostrap ? qu’est-ce ?
framework : oki pourquoi pas
sdk : quesaco.

Très grossièrement :

Le bootstrap, c’est la séquence de démarrage d’une application. Autrement dit, l’ensemble des fichiers, des globales, des constantes et des fonctions qui sont chargées par SPIP pour comprendre ce que demande un·e utilisateurice à travers une requête (sur le web ou en ligne de commande) aller chercher le code nécessaire à la production de la réponse et à sa restitution. Pour faire plus simple, le fichier ecrire/inc_version.php et les fichiers qu’il charge systématiquement avant d’analyser la demande etc.

Un SDK c’est un Software Development Kit. Dans notre cas, ça pourrait être le Spip Development Kit ;). C’est l’ensemble des outils permettant de développer quelque chose pour une technologie donnée. Dans notre cas, ça pourrait être des choses qui permettent de faire des tests, de l’analyse statique, des opérations de migrations pour transformer du code, entre autres.

Un framework, c’est un ensemble de composants spécialisés, par exemple dans la gestion de fichiers, d’accès à une base de données, de traitement des requêtes et des réponses des utilisateurices, d’internationalisation, de journalisation, …

2 « J'aime »

J’ai tout compris ! Merci… sauf « le titre ».

Moi je suis pas sûr d’avoir compris : l’idée général, c’est de remplacer l’attribut compat (au sens « compat à SPIP ») par une dépendance classique à un module composer central/cœur ?

Et SVP devra lire parfois paquet.xml, parfois les JSON, lock etc de Composer, pour savoir s’il peut activer un plugin dans tel contexte (= tel noyau de SPIP et tels plugins déjà présents) ?

···
-- 
RastaPopoulos

Pas de le remplacer: d’être une alternative.
On dit « package », pas module :wink:
Et oui, l’idée est bien d’exploiter composer pour ça, avec un package, ou plusieurs, on verra…

Alors, sauf erreur de ma part, la gestion des dépendances via paquet.xml est dans SPIP.

C’est en tout là où on parle d’activation mais surtout de vérification de la compatibilité qu’on pourra utiliser les données composer ou paquet.xml, selon ce qui est présent.

Je souhaiterais aussi à l’occasion de cette version majeure qu’on acte la fin de l’attribut categorie qui n’est plus nécessaire ni utilisé depuis spip 4 (actuellement en implied).

Je comprends que les fonctions actuelles de lecture des paquet.xml vérifieront où elles peuvent trouver les informations et renverront comme avant l’ensemble des informations, ce qui pourrait être presque indolore si c’est possible aussi simplement.

Par contre, j’ai toujours la même remarque depuis qu’on discute de ces sujets, quid de débardeur et de Plugins SPIP qui pour l’instant construit sa base de données à partir d’un archives.xml complet.
Je ne pense pas que ce soit un problème puisque les informations perdurent et ne font que changer de localisation mais il faut y penser. Juste un reminder.

Sinon j’ai pas tout compris au remplacement de l’attribut de compatibilité spip.
Et cet attribut où on désigne in fine un numéro de version est utilisé par SVP (critère) et aussi par Plugins SPIP. Si on le remplace par un lien vers un package comment imagine-t-on modifier le critère de compatibilité spip ?

Ok, je me note ça.

C’est l’objectif recherché, en effet, mais je ne vais pas l’atteindre en un week-end :wink:

Coté plugin, en changeant la valeur du require dans le fichier composer.json ? Mais j’ai l’impression que je réponds à coté… A priori, comme dit plus haut, les infos du plugin seront les mêmes, peu ou prou, en sortie des fonctions de lecture.

Je ne les remets pas en cause. A priori, l’idée est de rester compatible le temps qu’il faudra. S’il devient nécessaire d’aménager ces outils pour prendre en compte notre dépôt composer, on les adaptera.

Hello,

Mon week-end est tout chamboulé. Les propositions de code devraient arriver un soir de la semaine qui vient. Désolé.

J’ai brouillonné le début de la démarche dans le carnet wiki. Ç’est très technique, ça n’a pas vocation à devenir un article, une doc ou quoi que ce soit. En résumé:

Comme il y a 2 ans, l’analyse statique du code PHP des plugins « dist » avec phpstan met en évidence les points suivants:

  • Il y a 2052 appels à des fonctions PHP de SPIP lui-même dans les plugins (« dist »).
  • Ces appels correspondent à 330 fonctions « seulement ».
  • Ces fonctions sont déclarées dans 64 fichiers du « core ».
  • Ces 64 fichiers déclarent 1244 fonctions.

La suite sur ce sujet est de classer ces fonctions en thématiques techniques pour en déduire les « composants » du « framework » SPIP.

La nouveauté, c’est l’épluchage un peu brutal du « bootstrap » actuel de SPIP:

Les 5 fichiers ci-dessous sont chargés à chaque requêtes HTTP de manière inconditionnelle. Ils ne sont pas surchargeables. Ils déclarent 135 fonctions, des globales et des constantes qui vont demander un petit travail de classement aussi.

  • ecrire/inc_version.php
  • ecrire/inc/utils.php
  • ecrire/base/connect_sql.php
  • ecrire/base/objets.php
  • ecrire/inc/flock.php

Ce chargement de fichier s’appuie sur quelques constantes qui ont donc un rôle particulier :

  • _DIR_RESTREINT_ABS
  • _ROOT_RESTREINT
  • _FILE_OPTIONS
  • _CACHE_PLUGINS_OPT
  • _ROOT_CWD
  • _CACHE_PLUGINS_FCT
  • _CACHE_PLUGINS_PATH
  • _FILE_CHMOD
  • _FILE_CONNECT ou _FILE_CONNECT_TMP

J’en suis là. La suite demain soir. :wink:

1 « J'aime »

Hello,

Quelques stats dans ce magnifique document.

La première feuille résume le nombre de fonctions SPIP utilisées pour chacun des 20 plugin-dist. Plus il y en a, plus la dépendance est grande, plus ça signifie que le package « framework » risque d’être volumineux… ou, disons, riche en composants… ou qu’il serait bon de multiplier les packages à créer.

La deuxième feuille fournit le nombre d’appels fait en PHP dans SPIP pour chaque fonction. Plus elle est utilisée, plus elle a sa place dans un package de framework, surtout si elle est aussi utilisée dans un nombre important de plugins-dist. Moins elle est utilisée, plus ça pourrait justifier de la déplacer dans un plugins-dist.

à noter que include_spip, _T, _request, spip_log et charger_fonction, les plus « populaires », font partie du bootstrap de SPIP. Ce n’est sûrement pas un hasard. :slight_smile:

La dernière feuille inquique dans combien de plugins chaque fonctions est appelée (au moins une fois).

On peut déjà noter que le plugins archiviste n’appelle aucune fonction SPIP (il le fait dans la version 2.2, mais ce n’est plus nécessaire avec la branche master, pour SPIP5). Cela veut dire qu’il ne faudrait pas grand chose que qu’archiviste ne soit plus un plugin SPIP, mais un « simple » package composer, une « lib », qui pourrait être déplacer dans le dossier vendor/.

Un autre truc intéressant, il y a des fonctions déclarées dans SPIP que SPIP n’utilise pas ou vraiment très peu. Et une trentaine de fonctions utilisée 1 seule fois dans SPIP. Au lieu de les mettre dans un package framework, il faudrait les étudier, par thème technique ou au cas par cas, pour les déplacer dans un des plugins-dist. Enfin faut voir, quoi…

Bref, je pense que ça vaut le coup de pas se précipiter et de ne pas bêtement déplacer les 330 fonctions dans un package composer et basta. On peut faire des trucs plus fins.

Reste à classer par thème technique.

Le document n’est pas public :frowning:
En fait, si, à condition de ne pas être connecté (dans mon cas en tout cas)

Merci pour le récap :slight_smile:

Claro que si !

– Bonjour JamesRezo, tu vas bien ?
– Bah écoute heu… JamesRezo, c’est ça ? ok… bah ça peut aller. J’ai fini le classement…
– Ah cool ! Euh… pourquoi t’as fait ça au fait ?
– Euh, bah c’est pour tronçonner SPIP en petits morceaux, histoire de réduire les problèmes d’interdépendances du code, tu vois ? … non ? … bah en gros, c’est pour
– ouais, ok, c’est cool, merci. Donc, t’as fini. On peut voir ça quelque part ?
– ouais, c’est la quatrième feuille du doc là : spip-framework - Google Sheets. Mais c’est déjà caduque…
– hein ?
– ouais, y a eu pas mal d’activité cette semaine faut que je relance mes petites moulinettes
– ah, ok. Ce sera prêt quand alors ?
– j’sais pas… je suis un peu crevé, là. Plus tard ce soir ? ce week-end ?
– ok… À plus alors…

2 « J'aime »

Dans la famille des tâches aliénantes, je voudrais : classer toutes les fonctions du core.
Merci et force et courage comme dirait l’autre !

Salut,

Le doc est à jour. Les thématiques sont assez grossières et non-définitives, c’est à titre indicatif. Elles sont au nombre de 25. J’ai ajouté une cinquième feuille avec une belle matrice plugin/thème qui met en évidence les besoins des plugins (toujours dist) en terme de code.

Il y a un premier truc que j’aimerais explorer, c’est ce qui est lié aux fonctions d’iimages: On a un plugin images, on est des fonctions images dans SPIP, et une dépendance à ces fonctions dans d’autres plugins (bigup, dump, medias, mots, safehtml, stats).

Je déplacerais bien les fonctions de traitement d’images de spip dans le plugin images.

Bref, à suivre…

Merci,

je viens de faire un rapide survol
je m’interroge sur les catégories cms et sql.

Ex, en prenant le doc tel qu’actuellenent

objet_modifier ecrire/action/editer_objet.php ecrire/action cms
objet_modifier_champs ecrire/inc/modifier.php ecrire/inc sql
objet_optimiser_liens ecrire/action/editer_liens.php ecrire/action cms
objet_qualifier_liens ecrire/action/editer_liens.php ecrire/action cms
objet_test_si_publie ecrire/base/objets.php ecrire/base sql

Pour moi objet_test_si_publie devrait être cms, de même que objet_modifier_champs. En fait tout ce qui concerne les objets seraient CMS, alors que tout ce qui concerne les requete sql serait sql.

Pour les images : oui pour tout rapatrier à un seul endroit.

J’ai ajouté 2 feuilles:

« Caractéristiques Plugins » dans laquelle on trouve des informations sur le PHP des plugins mais aussi sur les ressources web (assets), le nombre de fichiers html (squelette), le nombre de lib JS.

L’idée est de voir combien de plugins pourraient devenir des packages composer qui seraient installés dans vendor/

Il y a 4 squelettes html dans le plugins images. Si on pouvait les mettre ailleurs, ce plugins deviendrait une « vraie » lib php…

Le dernière feuille concerne aussi le plugin images:

J’ai remis les fonctions SPIP liées à la thématique « images » et noter où elles étaient utilisées:

  • formats_image_acceptables() pourrait être déplacée dans le plugin medias
  • svg_force_viewBox_px() pourrait être déplacée dans le plugin safehtml
  • toutes les autres pourraient atterrir dans le plugin images
1 « J'aime »

Les squelettes du plugin images:

./plugins-dist/spip/images/modeles/favicon.html
./plugins-dist/spip/images/favicon.ico.html
./plugins-dist/spip/images/apple-touch-icon.png.html
./plugins-dist/spip/images/prive/squelettes/inclure/favicon-head.html

des trucs qui évoquent les favicon ailleurs:

./squelettes-dist/modeles/favicon.html
./squelettes-dist/favicon.ico.html
./squelettes-dist/spip.ico
./spip.svg
./spip.png

c’est juste un déplacement de fichiers, c’est pour tester :

Coucou,

Je bosse sur le recensement des constantes. Dans SPIP, il y en a presque 300 :

282 pour être précis : spip-framework - Google Sheets feuille « Constantes SPIP »

Reste à les associer à une thématique, déterminer si c’est surchageable ou pas, histoire de savoir comment on peut les transformer (si on peut)

On a aussi des constantes dans les plugins-dist : 119, feuille « Constantes plugins dist »
Il y aura le même taf à faire sur les globales…

1 « J'aime »