[spip-dev] Changer la gestion des catégories de plugin

Dev
#41

Oui, évidemment.

Mais je pense qu'il faut arrêter de vouloir cloisonner et imposer des
limites trop strictes.

Je dis ça, et on le sait, en faisant clairement partie de ceux qui
pensent que c'est bien si les gens utilisent au maximum les outils
communs de la communauté. MAIS dans le même temps, je pense qu'il ne
faut rien imposer.

Si les gens ont envie de pouvoir documenter ailleurs, que ce soit un
fichier MD dans le dépôt de code, ou dans un site séparé (comme
spipr.nursit) qui peut même parfois documenter plusieurs plugins d'un
même gros projet : on doit pouvoir le faire.

Et on doit pouvoir le faire en étant toujours bien référencé sur la
communauté quand même, quand on fait ce qu'il faut pour y être déclaré.
Ça permet de ne pas avoir des projets "fantomes" qu'en fait personne ne
connait et qui trainent, sans être listés chez nous aussi.

C'est d'ailleurs exactement ça : comme les dépôts packagist. D'ailleurs
à terme (plutôt moyen-long), on supprimera totalement archivelist et
notre listing sera à priori un sous-ensemble de packagist (une
extraction des projets composer déclarés comme étant de type "spip-plugin").

Seulement on est gentil et on propose *à ceux qui veulent* de faire leur
documentation sur nos outils communs.

#42

Re,

#43

Oui, par exemple.

Effectivement si on référence directement avec un modèle et la source, pas besoin de synchro d'un document.

Ça couvre déjà le cas de github, en récupérant automatiquement l'url raw depuis le nom du fichier et du dépot :
https://raw.githubusercontent.com/user/projet/master/readme.md

Ça me parait un bon plan.

#44

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...

Tiens, autre doc en markdown, celle de Project Fluent : là https://github.com/projectfluent/fluent/tree/master/guide
Qui se retrouve sur GitBook là : https://projectfluent.org/fluent/guide/

Mais… GitBook, qui semble être fait par une équipe lyonnaise, dans sa version 2 a un éditeur en ligne (tout beau, avec édition en place, et a priori propriétaire ? En tout cas ça ne semble plus là https://github.com/GitbookIO) qui stocke maintenant les données en JSON et plus en Markdown. Avec les explications du pourquoi (limitations) là https://docs.gitbook.com/v2-changes/important-differences#editing-markdown-source ; Je n’ai pas trouvé à quoi ressemble le JSON derrière…

Ce qui je trouve est intéressant vis-à-vis de la discussion markdown de l’autre côté. L’inconvénient clair pour moi du JSON est qu’il faut alors absolument un éditeur par dessus pour rédiger le contenu.

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

Pourquoi pas :slight_smile:

Une des possibilités est d’utiliser un conteneur de services. Le service 'log' (ou équivalent) retournerait un logger compatible avec la l’interface fournie de psr/log. Probablement Monolog s’il y en a un à choisir. Ou une implémentation SPIP qui reprendrait le fonctionnement historique qu’à spip_log. Est configurable quelque part la relation entre le service 'log' et l’implémentation utilisée.

Ceci fait, spip_log() elle même peut devenir dépréciée (ou pas) et utiliser alors le service de log directement.

MM.

#45

La signature de la fonction spip_log a mal évolué dans le temps.
Si ça devient obsolète, je ne regretterai pas le fait de devoir concaténer le nom du fichier de log et le niveau de log.

Mais j'imaginerai bien un tableau de bord permettant de régler certes le niveau de log global,
mais surtout permettant d'activer les logs sur telle ou telle fonctionnalité-fichier de log.

JLuc