Flex, le petit voisin de composer

Équipes architecture
1

Le dépôt composer de SPIP a un nouveau voisin, un dépôt flex: SPIP Flex recipes

Flex est un plugin composer. Il permet de faire, à l’instar du plugin composer pour spip, des opérations automatiques, à base de « recettes » (recipes), lors de la création/mise à jour d’un projet basé sur spip/spip.

Il est encore expérimental. Les recettes actuellement à disposition permettent de créer les récents fichiers de configuration des dossiers de SPIP qui « sortent » ainsi du dépôt git de SPIP ainsi que d’ajouter des lignes dans le fichiers .gitignore.

Une PR en draft est accessible ici Draft: Flex introduction (!6117) · Requêtes de fusion · spip / spip · GitLab pour les curieux.

4 « J'aime »
2

Quelques explications : la proposition ajoute symfony/flex dans SPIP, qui est un outil qui exécute des actions au moment des composer install ou composer update.

Ces actions peuvent être diverses, mais consistent souvent à créer, compléter ou mettre à jour des fichiers de configuration.

Pour connaître la liste des actions à réaliser, l’outil interroge un dépôt de recettes, et regarde s’il existe une recette pour telle ou telle librairie chargée via composer. Note: les recettes sont déclarées ailleurs que sur le git de la librairie installée (c’est un choix volontaire de symfony).

Dans de cas de SPIP par exemple, on déclare dans le composer.json un dépôt de recettes supplémentaire (pointant sur https://get.spip.net/flex/recipes/index.json), en plus de celui de symfony par défaut (dont les sources sont là GitHub - symfony/recipes: Symfony Recipes Repository).

Ce fichier, un peu comme pour le dépôt Composer à côté, déclare une liste de recettes existantes pour certains projets ; par exemple à l’heure où j’écris, il existe une recette pour spip-league/kernel à partir de sa version 1.0 ⁽¹⁾

Les actions réalisées sont déclarés pour chaque recette dans un fichier dédié, pour reprendre le même exemple, celui là : https://get.spip.net/flex/recipes/spip-league.kernel.1.0.json (dont les sources se trouvent (en ébauche) là Connexion · GitLab)

On trouve par exemple dedans une clé «manifest» qui complète une action de symfony : ici par exemple ajoutant des entrées dans le fichier .gitignore

                "gitignore": [
                    "/config/*.php",
                    "/plugins-dist/",
                    "/squelettes-dist/",
                    "/prive/",
                    "/ecrire/"
                ]

Ou encore la création d’un fichier de config

            "files": {
                "config/spip/routes.php": {
                    "contents": [
                        "<?php",
                        "",
                        "return [",
                        "    'front_office' => '/',",
                        "    'back_office' => 'ecrire/', # Should be /ecrire",
                        "];",
                        ""
                    ],
                    "executable": false
                },

Possiblement c’est peut être un moyen pour éditer le .htaccess par les plugins, mais pas certain qu’il y ait des choses adaptées : dans les «symfony/recipes-contrib», on trouve recipes-contrib/symfony/apache-pack/1.0 at ced96743676bdd5597ac364187945fa5f702ebf2 · symfony/recipes-contrib · GitHub mais il ne fait «que» créer le fichier .htaccess ; Et c’est la même chose pour les autres recipes de ce dépot de contribs.

⁽¹⁾
Flex prend la recette pour la version la plus haute déclarée par rapport à la librairie qu’on charge :

  • s’il y a déclaré 3 recettes spip-league/kernel 1.0 spip-league/kernel 1.1 et spip-league/kernel 1.2
  • et qu’on installe la lib spip-league/kernel 1.0, il exécutera les recettes pour 1.0. ;
  • si on installe spip-league/kernel 1.5 ou spip-league/kernel 2.0, il exécutera uniquement spip-league/kernel 1.2 (le plus haut déclaré) (mais pas les précédents 1.0, 1.1)

Autrement dit, ce n’est pas comme le tableau $maj des fichiers d’administrations de SPIP.
Chaque recipe indique l’ensemble des commandes qu’il doit exécuter à partir de cette version de la librairie.

3 « J'aime »
3

Notons qu’il y a une liste de commandes préconfigurées de Flex intéressantes

Pour

4

Alors ok mais ça reste très très vague et abstrait comme explication. :slight_smile:

Concrètement il faudrait que vous expliquiez à quoi ça sert de déporter ci ou ça dans des « recettes » externes, ailleurs que dans le code, dans un dépôt en ligne externe. Tout ça est très ésotérique… :hamsa::six_pointed_star:

Sachant qu’on éclate déjà le core dans un sacré paquet de dépôts de code différents (ecrire et prive ça c’est « facile », c’est un peu le code « qu’on connait », mais aussi tout ce qui est dans spip-league), et qu’il devient mécaniquement plus difficile d’avoir une vue d’ensemble¹, quel est le but d’avoir en plus des choses autre part que dans le code ?

Plus généralement, expliquer ce que fait une modif, comment ça fonctionne, même avec des exemples, ne permet pas de comprendre pourquoi il faudrait le faire, dans quel but.

¹ Je ne dis pas plus difficile de s’y retrouver, car en théorie si les découpages sont bien faits, à la fin c’est censé être pas trop compliqué de savoir que pour corriger tel aspect c’est dans tel dépôt (même si va comprendre la quantité et complexité de découpage de spip-league / path · GitLab par rapport à ce que faisait find_in_path et include_spip), mais donc bien plus difficile d’avoir une vue d’ensemble. Surtout quand on suit pas everyday la moindre modif et déplacement.

5

Je comprends bien que j’ai tenté de mettre directement quelques exemples dessous.

Je ne garantie pas de bien répondre, mais l’idée globale, je suppose, est d’avancer ultérieurement vers une intégration plus construite du cœur de symfony, de ses principes de routes / configurations (qui utilisent aussi flex).

En gros le dépot spip/spip ne fournit plus grand chose (en fichiers), il dit, via son composer.json de récupérer différents trucs. Il ne fournit même plus les répertoires « config », « IMG », « local », « tmp » : ils sont créés au moment de faire le composer create-project (ou équivalent composer run post-create-project-cmd après git pull du dépot)

Symfony flex fait un peu la continuité, tu vas pouvoir dire quand je charge tel ou tel package, par exemple spip/ecrire, je sais que je dois ajouter ceci ou cela dans le .gitignore racine, dans le répertoire config/ ; notamment tu sais que tu peux déclarer la route « ecrire/ » dans ce cas.

Comme j’ai montré aussi, tu peux recopier des assets/ … un des objectifs ultérieurs étant d’arriver à avoir SPIP qui puisse démarrer depuis un répertoire public/ (avec les assets, images, où pointe ton vhost dedans), et tout ou quasi du reste du code étant en dehors de ce répertoire, dans vendor/ notamment.

Pour le moment je reste aussi un peu sur «mouais», et même quand Flex est arrivé dans symfony, le fait que ça soit pas dans les dépots des librairies je trouvais ça étrange… mais en fait la logique est un peu différente : tu as dans ton dépot (git) une librairie qui fait telle chose (avec ses tests). Tu mets ailleurs comment on doit la configurer si elle est chargé dans un symfony, ou dans un spip, ou dans autre chose… c’est un peu ça les « recipes » : c’est comment dans ce logiciel je me configure pour fonctionner ; ça fait une sorte de bridge pour compléter / altérer les fichiers racines du projet… du moins c’est ce que j’en comprends.

Mais le temps a aussi fait son affaire chez symfony, et il faut bien dire que d’usage de Flex dans leur écosystème est bien foutu.

Maintenant sur le découpage… déjà spip-league/path, ça a plus d’un an maintenant :slight_smile: et il faut avoir mis le nez dans le code de find_in_path pour savoir que ce n’est pas aussi si simple que tu sembles le dire. Et donc oui, on découpe si possible pour isoler les fonctionnalités et leur tests au même endroit. C’est certainement pas parfait, loin de là, mais c’est plus simple de gérer des petites librairies individuellement, et leur tests / mises à jour / versions, qu’un gros paquet qui regroupe tout et ou lancer les tests prend 5 minutes du coup…

6

Merci pour cette tentative. :slight_smile:

Je pense avoir compris (même avec tes exemples de départ) ce que ça fait. Mais j’ai encore du mal à comprendre pourquoi ça aurait un quelconque intérêt par rapport à l’avoir dans le code, dans quel but ?

Bien sûr qu’on a des dépôts Git qui sont des libs de plus en plus autonomes sans rapport avec SPIP (ou même avec symfony), même dans nos productions à nous. Ça je l’ai bien compris et super.

Mais ensuite le dépôt racine qui décrit SPIP dist avec toutes les dépendances, et bien… justement lui il déclare toutes ces dépendances, donc il sait déjà que pour marcher il a besoin de ecrire/, et ceci cela. Donc logique qu’il ait ses propres fichiers de config pour le faire marcher lui-même, pourquoi ça aurait besoin de venir d’ailleurs, pour quel utilité ?

(Pour les assets, de toute façon tant qu’il est bien permis d’installer des plugins par le web, par nos dépôts ou par zip, ces plugins contiennent à la fois du code PHP et des squelettes et des css et des images et des js, dans le même dossier, donc faut toujours que tout soit accessible dans ces plugins, me semble-t-il)

7

Un des buts que je vois, même si pour l’heure c’est pas encore hyper abouti, c’est de pouvoir mieux travailler sur les tests unitaires.

L’idée c’est pouvoir lancer juste ceux sur les fonctions qu’on travaille. Mais aussi potentiellement de ne charger dans les tests unitaires d’un plugin que les fonctions de SPIP vraiment nécessaires pour tester (même si à terme l’idée serait qu’un minimum de fonction d’un plugin dependent de SPIP).

Et qui sait aussi, à terme, si on arrive à sortir la substantifique moelle de SPIP dans des petits modules utilisables par d’autres applications, trouver des devs pour nous aider aussi sur juste ces modules.

8

Je n’ai pas compris le rapport entre ce que tu dis là et ce sujet. :stuck_out_tongue:

On parle de Flex et des recettes de configs là, pas du découpage en modules indépendants. :slight_smile: