Re: Changer la gestion des catégories de pl ugin

Re,

Le dim. 19 mai 2019 à 11:30, Matthieu Marcillaud <[email protected]> a
écrit :

> > Faut juste penser que smart-paquets ne fait pas que compiler les données
> > contenues dans un paquet.xml ou un plugin.xml. Il construit des données
> > incluses dans le archives.xml comme les traductions.
>
> Il me semble que l’idée est bien de continuer à générer ce fichier (et
> donc à un moment il y a une phase d’analyse du code source, notamment de
> paquet.xml).
>
>
Ah ok, impec alors.
Mais ça me parait si évident.



> > Donc je ne sais pas comment une API sur un outil qui nous est externe et
> > sur lequel nous n'avons pas prise peut arriver à rendre un service
> > équivalent. C'est à étudier, je le répète depuis des semaines sans être
> > audible il semblerait, Composer me parait indolore dans l'étape initiale
> > sauf pour le référencement des plugins et c'est pour cela que j'ai lancé
> > les deux derniers fils.
>
> Heu, oui, enfin nous aussi on se répète…
>

De quoi tu parles ?
Moi je parle juste de ce sujet pas de Composer dans sa globalité.
La doc sur la migration vers Composer est très bien.

Le seul truc que je ne vois c'est où on en est du développement ?
Est-on proche d'avoir une version SPIP+dist Composer et Git ou pas ?
Qui travaille dessus, doit-on faire quelque chose ?

A ce propos, une petite aparté : je me suis mis "sérieusement" à git avec
Github pour les devs de Contrib, franchement c'est nickel Github !
Je reste sur ma position que Git est bien trop complexe pour 90% des
besoins mais avec Github on peut pratiquement faire du SVN-like en mieux
(par exemple, avec l'IDE Github Desktop).
Donc à mon avis y a pas à hésiter...


>
> > Ca serait donc bien que cette réflexion se fasse plus ouvertement
>
> Je vois pas en quoi ce n’est pas ouvert. C’est pas les mails qui
> manquent, ni les résumés des réflexions...
>

Encore une fois, je ne parle que de cette partie plutôt liée à
Smart-paquets.



>
> car je
> > sais par expérience que les fonctions de SVP, ses modules connexes et
> > smart-paquets sont mal connues.
>
> Certes, mais on est peut être pas obligé de reproduire le fonctionnement
> à l’identique.
>

Ca ça se discute justement ;-).
Tu es d'ailleurs dans un fil qui discute des fonctions de SVP...


>
> > Si je comprends bien c'est une autre façon de construire le
> > archivelist.txt non ?
> Oui, enfin ça ne le reconstruit pas à proprement parler, mais oui, ça
> crée une liste d’urls sources de plugins.
>
>
Oui c'est ça, c'est ce que je voulais dire.



> [...]
> > et de qualité, ce qui n'est pas le cas des readme que j'ai pu
> > lire, loin de là...
>
> Alors peut être chez SPIP, mais sur d’autres projets le readme est un
> très bon point d’entrée, qui me semble à encourager au contraire (parce
> que standard justement).
>

Je vais pas mettre mes exemples car c'est du SPIP ;-)


>
> Un petit exemple : https://github.com/Seldaek/monolog
> Le readme et la doc/ correspond à la branche du plugin que tu regardes.
> Tu fais une nouvelle version dans une nouvelle branche ? tu adaptes ta
> doc à côté, elle est à jour pour cette branche. Il y a un côté à la fois
> pratique et simple, et la doc est associée au code. Par contre, il n’y a
> pas de traductions (en tout cas dans cet exemple là).
>
> Ce qui n’empêche pas d’avoir une doc collective éditoriale à côté
> heureusement, mais en tout cas comme base, c’est ce qui me parait le
> plus sain.
>

Oui, c'est bien mais je trouve que la lecture sous github est cette fois
plus difficile.
Je pense que c'est du à la police et à la présentation.
Mais oui, y a surement de la doc bien faite, le problème c'est la
statistique sur le sujet...

Monolog c'est le premier module qui rentrera dans le SPIP-git-composer ? ;-)
Ca a l'air très bien.

++
Eric