Perdu dans les chemins / l'installation

maieul · Mai 28, 2023, 1:00

Hop,
je ne sais pas si le bug est dans SPIP ou plus probablement entre la chaise et le clavier. Mais il m’est arrivé une mésaventure et je ne sais pas par quel bout prendre, car c’est lié je pense aux changements en cours dans le processus de dev de SPIP, que je ne suis plus tout à fait.

J’ai voulu sur demande de @JamesRezo tester une branche du plugin-dist archiviste « dans un contexte spip 5 ». #4435 - zipper à plat - archiviste - SPIP on GIT. En l’occurence la branche zipper-a-plat

Et c’est là que les ennuis ont commencé.

J’avais une install qui correspond en gros à mon spip bac à sable. C’était installé via checkout, sur le tage 4.2.2
J’ai donc fait checkout spip .
Tout semble bien se passer a priori : bascule sur master, et j’obtiens ceci :

Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 20 installs, 0 updates, 0 removals
  - Downloading spip/mediabox (dev-master acbae3c)

etc pour l’ensemble des plugins-dist

SAUF QUE je ne fais pas attention que les plugins-dist ne sont plus dans plugins-dist mais dans plugins-dist mais dans plugins-dist/spip.

Alors du coup question n°1 : est-ce normal ce changement de chemin ? Si oui pourquoi

Bref, ne m’apercevant pas de cela, je me rend sur plugins-dist/archiviste (qui existe bel et bien, puisque je partais d’une install historique).

Du coup question n°2 : n’y a-t-il pas un bug dans le script checkout qui aurait du effacer ces plugins-dist à la racine ?

Pour comprendre ces 2 questions, rappelons l’état du dossier plugins-dist après mon appel du script checkout.

plugins-dist/
| - aide/
| - archiviste/
| - bigup/
| ...
| - spip/
  | - aide/
  | - archiviste/
  | -bigup/ 
  | ...
| ....

Bref une fois dans plugin-dist/archiviste je fais un git pull puis git co zipper-a-plat. Je me rend ensuite dans mon plugin pas dist zippeur et je teste les fonctionnalités de la branche.

Et j’arrive à obtenir ce que je veux… à quelques limites près. Le code auquel j’aboutit se trouve ici https://git.spip.net/spip-contrib-extensions/zippeur/commit/40cebd3e6991307d4201d80159e58307aead90c7.

Sauf que je vois passer un message de warning

Deprecated: inc/archives is deprecated. use Spip\Archiver\SpipArchiver instead. in /home/mrouquet/Sites/dev/spip-dev.test/plugins-dist/archiviste/inc/archives.php on line 25

J’attire votre attention : l’erreur est pointé dans plugins-dist/archiviste et non pas dans plugins-dist/spip/archiviste.

Je modifie le code de zippeur avec ceci

c’est à dire en obéissant scrupuleusement au code qui me dit de changer de classe .

Et j’obtiens alors l’erreur suivante :
Warning: ZipArchive::addFile(): No such file or directory in /home/mrouquet/Sites/dev/spip-dev.test/plugins-dist/spip/archiviste/src/ZipArchive.php on line *60*

Et là je ne comprend pas… je regarde le code, je vois que normalement l’ancienne classe a été mappé sur la nouvelle, donc ce qui marchait avec l’ancienne devait marcher avec la nouvelle.

(Question n°3 (subsidiaire) : pourquoi ces changements de nom entre Archives et Archiver ?)

Et je finis par comprendre : le fichier appelé est dans plugins-dist/spip/archiviste et non pas plugins-dist/archiviste.

D’où ma question n°4 : commencent cela se fait-il, alors que l’interface graphique de svp me dit que archiviste c’est plugins-dist/archiviste et pas plugins-dist/spip-archiviste. J’imagine que c’est une histoire d’autoloader, mais est-ce que cela ne traduirait pas un bug ou un tout cas un comportement différent entre l’autoloader et le find_in_path() habituel ?

Ayant compris cela je me rend dans plugins-dist/spip/archiviste pour me dire "il suffit que je bascule sur la branche zipper-a-plat dans le bon dossier et cela devrait marcher.

Mais impossible de le faire puisque plugins-dist/spip/archiviste ne pas un clone de spip/archiviste - archiviste - SPIP on GIT.

D’où ma question n°5 : comment est-ce que l’on tests une branche de dev d’un plugin lorsqu’on a utilisé le script checkout ?

Je me suis dit : supprimer plugins-dist/spip/archiviste au moins pour le teste, sauf que patatra Erreur d’exécution ../plugins/zippeur/modeles/zip_doc_article.html | File […]/plugins/zippeur/zippeur_fonctions.php Line 141 : Class "Spip\Archiver\SpipArchiver" not found.

J’imagine que l’autoloader ne marche pas…

marcimat · Mai 28, 2023, 4:39

oui, c’est du au passage du chargement des plugin-dist via Composer, et non plus via plugins-dist.json + checkout. Pour les plugins-dist SPIP on dit à Composer de les ranger dans plugins-dist/ mais, à l’instar de vendor/, il range par organisation (ici ces plugins étant dans l’orga spip/)

Tu peux faire éventuellement un ticket et une PR sur le script checkout, mais non il ne prévoit pas les suppressions de plugins-dist enlevés, lors d’une mise à jour tel que tu as faite.

Oui mais non… Composer a créé un autoloader pour plugins-dist/spip/archiviste/src
Pas pour ton ancien chemin de plugin dont Composer n’a pas connaissance.

Ce faisant tous les use Spip\Archiver\SpipArchiver sont voués à l’échec (du moins il vont chercher dans plugins-dist/spip/archiviste/src qui est resté sur la branche master et pas dans la branche zipper-a-plat que tu souhaites tester.

Tu t’en es aperçu après

Ce sont 2 mondes totalement différents justement ! C’est normal une différence de comportement.
L’autoloader de Composer est (relativement) fixe une fois généré (activer ou desactiver des plugins dans l’interface SPIP ne modifierait pas l’autoloader de Composer — du moins sans une manipulation en plus en ligne de commande…)

On préfère les verbes, tout simplement, je suppose

C’est bien d’arriver après la bataille, mais je sais pas ? Lire Dépot composer et "packages" pour SPIP - #12 par JamesRezo par exemple

Donc par défaut Composer récupère des «zips» des archives parce que c’est bien moins lourd et plus rapide.
On peut vouloir dire à composer de tout le temps récupérer des sources (git), ou le faire pour certains dépots ou organisations uniquement.

C’est ce que ferait dans composer.json cette config pour l’orga spip/ :

    "config": {
        "preferred-install": {
            "spip/*": "source"
        }
    },

Note que pour que ce soit pris en compte il faut supprimer le vendor/ ou le plugins-dist/ et relancer composer install.

L’inconvénient de cela, c’est qu’il crée un diff dans le composer.json de SPIP, pour quelque chose qui est du domaine du développeur, et que tu as pas envie de commiter.

James a crée une commande composer local copie un peu de composer global qui duplique le composer.json en composer.local.json et utilise ce dernier.
Dedans, la commande spéciale composer local mode-dev va ajouter ce qu’il faut pour que les plugins dist soient récupérés en Git (et une fois fait d’ailleurs, Composer continue d’utiliser le git ensuite).

Donc tldr:

rm -rf plugins-dist/*
composer local mode-dev
composer local install

Tu auras tes plugins-dist/spip/* en Git.

nicod · Mai 28, 2023, 5:07

De mon côté, j’avais bien lu en détail et testé, mais pas compris ce que faisait la commande local et surtout, ce passage là m’avait complètement échappé (pas compris que ça parlait de source git) :

Donc merci pour tes explications un peu plus détaillées, je comprends mieux.

nicod · Mai 28, 2023, 5:24

Par contre, est ce normal qu’avec une installation simple, sans local, trois plugins dist (mediabox, svp et tw) soient en version git (avec un répertoire .git) ?
Je sais que c’est un travail en cours, donc c’est peut être lié, mais j’avoue que ça n’a pas aidé à ma compréhension.

maieul · Mai 28, 2023, 5:34

Merci @marcimat pour ta réponse.

J’avais bien vu passé le fil, je l’avais lu à l’époque mais quand @JamesRezo m’a demandé ce matin de faire le test je n’avais pas eu l’occasion/temps de mettre en pratique. Par ailleurs en recherchant ce matin de l’aide, j’ai cherché dans le fil consacré à SPIP 5 mais j’avais oublié celui consacré à composer et packages… et j’avais oublié l’existence. Enfin, le relisant après coup, je suis comme @nicod : je pense que je n’aurais pas pu m’en sortir avec ce seul fil, sans tes réponse.

EN tout cas « tout marche » désormais.

marcimat · Mai 28, 2023, 6:04

Oui c’est en chantier.

Détaillons un peu : par défaut Composer récupère si possible ce qu’on lui demande dans un format d’archive (zip), et s’il ne trouve pas, il va pécho le dépot Git. Quand il sait faire il peut s’appuyer sur l’API de la forge pour obtenir un zip (tel que Github). C’est pas le cas ici, on doit passer par un Satis derrière pour les zips (actuellement là: spip/composer).

Si on regarde un extrait des require actuel du master, on a :

        "spip/images": "^4.2.x-dev",
        "spip/mediabox": "^3.2.x-dev",
        "spip/medias": "^4.2.x-dev",
        "spip/mots": "^4.2.x-dev",

Les .x-dev comme tu le vois indique : on utilise cette branche à jour. Ça ce sont des require temporaire. À terme on devrait avoir quelque chose comme ^4.2 par exemple ou ^4.2.2 qui cherchera la plus haute version publiée (tags) toujours dans la version 4 (avec 4.2 minimum) ou 4.2 (avec 4.2.2 minimum)

Actuellement on génère les zips via un Satis pour les tag, et quelques branches.

Si on regarde

pour Mediabox par exemple, on voit là spip/composer qu’il a un zip pour 3.1.x-dev ~~mais pas pour 3.2.x-dev ni dev-master~~ [edit: ah bah si !]
contrairement à Images là spip/composer qui a un dev-master indiqué aussi alias de 4.2.x-dev

Du coup dans le cadre de spip/images : il sait retouver un zip, pas dans le cadre de spip/mediabox actuellement.

Alors mais qu’est-ce donc que tout de bretzel au final :

dans Images : composer.json · master · spip / images · GitLab un alias est déclaré (4.2.x-dev)
dans Mediabox : composer.json · master · spip / mediabox · GitLab (3.2.x-dev)

~~J’en conclue que le Satis n’est pas à jour de ces alias là pour certains dépots (au moins Médiabox).~~ Edit: en fait je ne sais pas du coup !

Peut être que @JamesRezo saura en dire plus

JamesRezo · Mai 28, 2023, 6:28

C’était le composer.lock de spip/spip qui n’était pas à jour. je viens de le pousser.

nicod · Mai 28, 2023, 6:29

Merci, entre temps j’ai remarqué effectivement que composer se rabattait sur les sources git :

  - Downloading spip/tw (dev-master 4123cd0)
 0/3 [>---------------------------]   0%    Failed to download spip/mediabox from dist: The "https://get.spip.net/composer/dist/spip/mediabox/spip-mediabox-dev-master-136bd7.zip" file could not be downloaded (HTTP/2 404 )
    Now trying to download from source
  - Syncing spip/mediabox (dev-master acbae3c) into cache
    Failed to download spip/tw from dist: The "https://get.spip.net/composer/dist/spip/tw/spip-tw-dev-master-002010.zip" file could not be downloaded (HTTP/2 404 )
    Now trying to download from source
  - Syncing spip/tw (dev-master 4123cd0) into cache

 2/3 [==================>---------]  66%    Failed to download spip/svp from dist: The "https://get.spip.net/composer/dist/spip/svp/spip-svp-dev-master-7e95f6.zip" file could not be downloaded (HTTP/2 404 )
    Now trying to download from source

EDIT : non pardon, là c’était sur une 4.2… Je fais des tests et je m’embrouille…

EDIT2: en fait non mais c’était sur une 4.2 avec checkout -bmaster sans préciser . comme destination donc il travaillait dans un sous répertoire spip. Bref…

marcimat · Mai 28, 2023, 10:20

Le mode-dev fait plusieurs choses : il ajoute la config preferred-install (c’est ça qui va mettre en git au final) et il propose de passer les urls git en ssh (pour faciliter les commits pour les devs) (parce que par défaut elles sont en https (et du coup sans clé ssh)