[spip-dev] Smart-Paquets, traductions, dépôts...

eric_tonton · Mars 19, 2011, 3:32

Hello,

J’ai terminé un premier ensemble de modifications concernant l’outil Smart-Paquets qui génère l’ensemble des zips de la Zone.
Ces modifications sont les suivantes :

Paramétrage complet de l’appel de la fonction principale.
Réorganisation du code et commentaire
Ajout de la génération du fichier traductions.txt utilisé par Salvatore (expérimental)
Ajout de la compilation des informations de traduction des plugins
Génération des logos de chaque plugin

Ces modifications nous permettent aujourd’hui d’envisager les évolutions suivantes :

SVP
SVP va pouvoir afficher toutes les informations sur les plugins y compris la liste des traductions.
Le site de démo http://svp.smellup.net sera rapidement mis à jour pour proposer ces nouveaux affichages.
Gestion des dépôts multiples
Il est possible d’une part d’utiliser Smart-Paquets sur tout autre repository SVN que SPIP-Zone, et d’autre part, de définir plusieurs dépôts logiques sur le même repository .
Par exemple, on pourrait créer, pour SPIP-Zone un dépôt pour les plugins “récents”, un autre pour les “vieux” plugins qui n’évoluent plus ou peu. L’intérêt : adapter les récurrences de génération au besoin réel et de permettre de filtrer les pages SVP par dépôt.
Traductions et évolutions de Salvatore
Aujourd’hui Salvatore pourrait utiliser le fichier traductions.txt généré par Smart-Paquets pour connaitre la liste des plugins à traduire. Il lui faudrait juste rajouter les fichiers de langues de SPIP et certains outils spécifiques.
En outre, Smart-Paquets sachant lire aujourd’hui les rapports de traduction au format XML (cf l’article http://blog.smellup.net/spip.php?article31) il est possible de faire évoluer Salvatore pour générer ces fameux rapports.

Comme je l’ai dit aussi dans mon dernier commit, je serais d’avis de rajouter systématiquement une balise dans le plugin.xml afin de lister les modules du plugin. En effet, il n’y a pas de moyen simple et déterministe vu la nomenclature des fichiers de langues pour connaitre la liste des modules traduits.

Voilà voilà…

Piero_Wbmstr · Mars 24, 2011, 7:26

Salut,
Je reviens sur ce mail qui a retenu mon attention …

En effet, le point 2) indique qu’il serait (ou « est déjà » ?) possible de faire générer par la zone des paquets depuis un dépôt distant, ce qui m’intéresse précisément car j’ai quelques plugins proposés sur Contrib en dév sur un SVN perso.
De coup, Eric, peux-tu détailler la procédure ? Est-elle déjà en place ou est-ce une proposition d’évolution ?

Merci, et bravo pour tout ce boulot
– PiWi

Le 19 mars 2011 à 16:32, Eric a écrit :

Hello,

J’ai terminé un premier ensemble de modifications concernant l’outil Smart-Paquets qui génère l’ensemble des zips de la Zone.
Ces modifications sont les suivantes :

Paramétrage complet de l’appel de la fonction principale.

Réorganisation du code et commentaire

Ajout de la génération du fichier traductions.txt utilisé par Salvatore (expérimental)

Ajout de la compilation des informations de traduction des plugins

Génération des logos de chaque plugin

Ces modifications nous permettent aujourd’hui d’envisager les évolutions suivantes :

SVP
SVP va pouvoir afficher toutes les informations sur les plugins y compris la liste des traductions.
Le site de démo http://svp.smellup.net sera rapidement mis à jour pour proposer ces nouveaux affichages.

Gestion des dépôts multiples
Il est possible d’une part d’utiliser Smart-Paquets sur tout autre repository SVN que SPIP-Zone, et d’autre part, de définir plusieurs dépôts logiques sur le même repository .
Par exemple, on pourrait créer, pour SPIP-Zone un dépôt pour les plugins « récents », un autre pour les « vieux » plugins qui n’évoluent plus ou peu. L’intérêt : adapter les récurrences de génération au besoin réel et de permettre de filtrer les pages SVP par dépôt.

Traductions et évolutions de Salvatore
Aujourd’hui Salvatore pourrait utiliser le fichier traductions.txt généré par Smart-Paquets pour connaitre la liste des plugins à traduire. Il lui faudrait juste rajouter les fichiers de langues de SPIP et certains outils spécifiques.
En outre, Smart-Paquets sachant lire aujourd’hui les rapports de traduction au format XML (cf l’article http://blog.smellup.net/spip.php?article31) il est possible de faire évoluer Salvatore pour générer ces fameux rapports.

Comme je l’ai dit aussi dans mon dernier commit, je serais d’avis de rajouter systématiquement une balise dans le plugin.xml afin de lister les modules du plugin. En effet, il n’y a pas de moyen simple et déterministe vu la nomenclature des fichiers de langues pour connaitre la liste des modules traduits.

Voilà voilà…

++
Eric

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

eric_tonton · Mars 24, 2011, 8:19

Hello,

Le 24 mars 2011 08:26, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

En effet, le point 2) indique qu’il serait (ou « est déjà » ?) possible de faire générer par la zone des paquets depuis un dépôt distant, ce qui m’intéresse précisément car j’ai quelques plugins proposés sur Contrib en dév sur un SVN perso.
De coup, Eric, peux-tu détailler la procédure ? Est-elle déjà en place ou est-ce une proposition d’évolution ?

C’est tout à fait opérationnel oui si tu veux créer ton propre dépôt à partir de ton repository svn.
La démarche est la suivante :

Créer un archivelist.txt (le nom importe peu) à l’instar de celui de SPIP-Zone. Regarde l’en-tête de celui de la zone pour voir les infos de base du dépôt qui seront chargées en base lors de l’ajout du dépot dans SVP. Le contenu correspond à la liste des zips que tu veux générer comme sur la zone. Ce fichier doit être à la racine de ton repository svn.
Installer et configurer smart-paquets
L’outil smart-paquets est dans la zone sous outils/.
Tu installes les fichiers dans un répertoire de ton serveur qui accueillera in fine les zips produits.
Tu crées, à partir des exemples existant qui sont relatifs à la zone, le script qui te convient. Par exemple, le fichier cron-paquets-00.sh et tu donnes tes paramètres personnels en regardant les commentaires qui sont assez détaillés dans le fichier empaqueteur.php ou dans la fonction empaqueteur du fichier inc_empaqueteur.php
Lancement de smart-paquets
En lancant le script tu vas obtenir un sous-repertoire paquets/ ou autre si tu as changé le nom dans lequel tu auras :

les zips demandés
les logos des plugins si ils existent
le fichier archives.xml (ou autre si tu as changé le nom)
un fichier traductions.txt eventuellement
un fichier logos.php qui est un index des logos

Définir une url sur le répertoire des paquets
Donc maintenant si le répertoire précédent est bien rempli tu peux définir une url sur ce répertoire et donc tout son contenu sera utilisable.
Utiliser SVP
Maintenant, ton dépôt est utilisable. Soit tu me donnes son url et je le rajoute dans la liste sur le site de démo svp.smellup.net et on pourra le voir comme celui de mathieu ou comme la zone.
Sinon tu peux aussi te faire un test en installant SVP, zcore et zdist sur un site pour voir comment marche SVP et l’utiliser dans le privé et dans le public.

N’hésite pas si ce n’est pas totalement clair

++
Eric

Piero_Wbmstr · Mars 24, 2011, 3:26

Merci pour toutes ces infos …

N’hésite pas si ce n’est pas totalement clair

Ca m’a l’air clair et très complet
Je teste de suite et ferai un retour d’expérience.

Merci encore pour ce boulot!

– PiWi

Le 24 mars 2011 à 09:19, Eric a écrit :

Hello,

Le 24 mars 2011 08:26, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

En effet, le point 2) indique qu’il serait (ou « est déjà » ?) possible de faire générer par la zone des paquets depuis un dépôt distant, ce qui m’intéresse précisément car j’ai quelques plugins proposés sur Contrib en dév sur un SVN perso.
De coup, Eric, peux-tu détailler la procédure ? Est-elle déjà en place ou est-ce une proposition d’évolution ?

C’est tout à fait opérationnel oui si tu veux créer ton propre dépôt à partir de ton repository svn.
La démarche est la suivante :

Créer un archivelist.txt (le nom importe peu) à l’instar de celui de SPIP-Zone. Regarde l’en-tête de celui de la zone pour voir les infos de base du dépôt qui seront chargées en base lors de l’ajout du dépot dans SVP. Le contenu correspond à la liste des zips que tu veux générer comme sur la zone. Ce fichier doit être à la racine de ton repository svn.

Installer et configurer smart-paquets
L’outil smart-paquets est dans la zone sous outils/.
Tu installes les fichiers dans un répertoire de ton serveur qui accueillera in fine les zips produits.
Tu crées, à partir des exemples existant qui sont relatifs à la zone, le script qui te convient. Par exemple, le fichier cron-paquets-00.sh et tu donnes tes paramètres personnels en regardant les commentaires qui sont assez détaillés dans le fichier empaqueteur.php ou dans la fonction empaqueteur du fichier inc_empaqueteur.php

Lancement de smart-paquets
En lancant le script tu vas obtenir un sous-repertoire paquets/ ou autre si tu as changé le nom dans lequel tu auras :

les zips demandés

les logos des plugins si ils existent

le fichier archives.xml (ou autre si tu as changé le nom)

un fichier traductions.txt eventuellement

un fichier logos.php qui est un index des logos

Définir une url sur le répertoire des paquets
Donc maintenant si le répertoire précédent est bien rempli tu peux définir une url sur ce répertoire et donc tout son contenu sera utilisable.

Utiliser SVP
Maintenant, ton dépôt est utilisable. Soit tu me donnes son url et je le rajoute dans la liste sur le site de démo svp.smellup.net et on pourra le voir comme celui de mathieu ou comme la zone.
Sinon tu peux aussi te faire un test en installant SVP, zcore et zdist sur un site pour voir comment marche SVP et l’utiliser dans le privé et dans le public.

N’hésite pas si ce n’est pas totalement clair

++
Eric

eric_tonton · Mars 24, 2011, 3:32

Yep,

Le 24 mars 2011 16:26, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

Je teste de suite et ferai un retour d’expérience.

Cool, je reste à l’écoute

++
Eric

Piero_Wbmstr · Mars 24, 2011, 8:57

Ca dépote … ça décape … ça déglingue … ça déchire !!

La config est vraiment simple, tout roule super.
Et pourtant dans mon cas c’était pas gagné : mon SVN n’est pas accessible au plubic (par HTTP) et mes plugins SPIP sont perdus dans la masse d’un dépôt global de plusieurs gigas.
Et pourtant, ça marche comme sur des roulettes. Comme si le gars, il avait fait ça pour que ça fasse exactement c’que ça fait …
Le résultat parle de lui-même : http://projets.pierowbmstr.fr/SPIP_paquets/
Du coup je re-dis BRAVO !

J’ai volontairement remis les mails originaux ci-dessous pour un historique complet.
D’ailleurs, ton explication par mail était nickel … elle a sa place dans le blog smellup non ? (j’y ai pas trouvé d’équivalent …).

Bon, j’ai évidemment quelques petites remarques (on s’refait pas) :

concernant le squelette : en page publique ‹ plugin.html ›, les entrées du tableau d’informations du plugin ne sont pas passées par « propre » ({les liens apparaissent entre crochets pour les lignes ‹ Auteur › et ‹ Licence › notamment}),
en partie privée, j’ai été un peu dérouté de ne plus retrouver l’éternelle liste des plugins en téléchargement, par contre le formulaire de recherche est super … peut-être pourrait-il être proposé en plus, sans forcément remplacer la liste existante, qui a l’avantage de permettre une mise à jour rapide si on sait de quel plugin il s’agit,
plus quelques fautes d’orthographes sans importance

Je me suis demandé au passage quelles infos pouvaient être définies dans le fichier « archivelist.txt » concernant le dépôt (infos type « DockBlocks » en haut) ?? Est-ce que tout tag est inclus au XML ? Peut-on par exemple définir un logo pour le dépôt ?

Bref, ça va devenir mon nouvel indispensable SPIP …
Chapeau bas

– PiWi

Le 24 mars 2011 à 09:19, Eric a écrit :

Hello,

Le 24 mars 2011 08:26, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

En effet, le point 2) indique qu’il serait (ou « est déjà » ?) possible de faire générer par la zone des paquets depuis un dépôt distant, ce qui m’intéresse précisément car j’ai quelques plugins proposés sur Contrib en dév sur un SVN perso.
De coup, Eric, peux-tu détailler la procédure ? Est-elle déjà en place ou est-ce une proposition d’évolution ?

C’est tout à fait opérationnel oui si tu veux créer ton propre dépôt à partir de ton repository svn.
La démarche est la suivante :

Créer un archivelist.txt (le nom importe peu) à l’instar de celui de SPIP-Zone. Regarde l’en-tête de celui de la zone pour voir les infos de base du dépôt qui seront chargées en base lors de l’ajout du dépot dans SVP. Le contenu correspond à la liste des zips que tu veux générer comme sur la zone. Ce fichier doit être à la racine de ton repository svn.

Installer et configurer smart-paquets
L’outil smart-paquets est dans la zone sous outils/.
Tu installes les fichiers dans un répertoire de ton serveur qui accueillera in fine les zips produits.
Tu crées, à partir des exemples existant qui sont relatifs à la zone, le script qui te convient. Par exemple, le fichier cron-paquets-00.sh et tu donnes tes paramètres personnels en regardant les commentaires qui sont assez détaillés dans le fichier empaqueteur.php ou dans la fonction empaqueteur du fichier inc_empaqueteur.php

Lancement de smart-paquets
En lancant le script tu vas obtenir un sous-repertoire paquets/ ou autre si tu as changé le nom dans lequel tu auras :

les zips demandés

les logos des plugins si ils existent

le fichier archives.xml (ou autre si tu as changé le nom)

un fichier traductions.txt eventuellement

un fichier logos.php qui est un index des logos

Définir une url sur le répertoire des paquets
Donc maintenant si le répertoire précédent est bien rempli tu peux définir une url sur ce répertoire et donc tout son contenu sera utilisable.

Utiliser SVP
Maintenant, ton dépôt est utilisable. Soit tu me donnes son url et je le rajoute dans la liste sur le site de démo svp.smellup.net et on pourra le voir comme celui de mathieu ou comme la zone.
Sinon tu peux aussi te faire un test en installant SVP, zcore et zdist sur un site pour voir comment marche SVP et l’utiliser dans le privé et dans le public.

N’hésite pas si ce n’est pas totalement clair

++
Eric

Le 19 mars 2011 à 16:32, Eric a écrit :

Hello,

J’ai terminé un premier ensemble de modifications concernant l’outil Smart-Paquets qui génère l’ensemble des zips de la Zone.
Ces modifications sont les suivantes :

Paramétrage complet de l’appel de la fonction principale.

Réorganisation du code et commentaire

Ajout de la génération du fichier traductions.txt utilisé par Salvatore (expérimental)

Ajout de la compilation des informations de traduction des plugins

Génération des logos de chaque plugin

Ces modifications nous permettent aujourd’hui d’envisager les évolutions suivantes :

SVP
SVP va pouvoir afficher toutes les informations sur les plugins y compris la liste des traductions.
Le site de démo http://svp.smellup.net sera rapidement mis à jour pour proposer ces nouveaux affichages.

Gestion des dépôts multiples
Il est possible d’une part d’utiliser Smart-Paquets sur tout autre repository SVN que SPIP-Zone, et d’autre part, de définir plusieurs dépôts logiques sur le même repository .
Par exemple, on pourrait créer, pour SPIP-Zone un dépôt pour les plugins « récents », un autre pour les « vieux » plugins qui n’évoluent plus ou peu. L’intérêt : adapter les récurrences de génération au besoin réel et de permettre de filtrer les pages SVP par dépôt.

Traductions et évolutions de Salvatore
Aujourd’hui Salvatore pourrait utiliser le fichier traductions.txt généré par Smart-Paquets pour connaitre la liste des plugins à traduire. Il lui faudrait juste rajouter les fichiers de langues de SPIP et certains outils spécifiques.
En outre, Smart-Paquets sachant lire aujourd’hui les rapports de traduction au format XML (cf l’article http://blog.smellup.net/spip.php?article31) il est possible de faire évoluer Salvatore pour générer ces fameux rapports.

Comme je l’ai dit aussi dans mon dernier commit, je serais d’avis de rajouter systématiquement une balise dans le plugin.xml afin de lister les modules du plugin. En effet, il n’y a pas de moyen simple et déterministe vu la nomenclature des fichiers de langues pour connaitre la liste des modules traduits.

Voilà voilà…

++
Eric

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

cerdic · Mars 24, 2011, 9:10

Le 24 mars 2011 à 21:57, PieroWbmstr a écrit :

Ca dépote … ça décape … ça déglingue … ça déchire !!

La config est vraiment simple, tout roule super.
Et pourtant dans mon cas c’était pas gagné : mon SVN n’est pas accessible au plubic (par HTTP) et mes plugins SPIP sont perdus dans la masse d’un dépôt global de plusieurs gigas.
Et pourtant, ça marche comme sur des roulettes. Comme si le gars, il avait fait ça pour que ça fasse exactement c’que ça fait …
Le résultat parle de lui-même : http://projets.pierowbmstr.fr/SPIP_paquets/
Du coup je re-dis BRAVO !

J’ai volontairement remis les mails originaux ci-dessous pour un historique complet.
D’ailleurs, ton explication par mail était nickel … elle a sa place dans le blog smellup non ? (j’y ai pas trouvé d’équivalent …).

Bon, j’ai évidemment quelques petites remarques (on s’refait pas) :

concernant le squelette : en page publique ‹ plugin.html ›, les entrées du tableau d’informations du plugin ne sont pas passées par « propre » ({les liens apparaissent entre crochets pour les lignes ‹ Auteur › et ‹ Licence › notamment}),

en partie privée, j’ai été un peu dérouté de ne plus retrouver l’éternelle liste des plugins en téléchargement, par contre le formulaire de recherche est super … peut-être pourrait-il être proposé en plus, sans forcément remplacer la liste existante, qui a l’avantage de permettre une mise à jour rapide si on sait de quel plugin il s’agit,

plus quelques fautes d’orthographes sans importance

Je me suis demandé au passage quelles infos pouvaient être définies dans le fichier « archivelist.txt » concernant le dépôt (infos type « DockBlocks » en haut) ?? Est-ce que tout tag est inclus au XML ? Peut-on par exemple définir un logo pour le dépôt ?

Bref, ça va devenir mon nouvel indispensable SPIP …
Chapeau bas

Ah bin c’est top que ça marche si bien !

Cédric

eric_tonton · Mars 25, 2011, 8:28

Hello,

Le 24 mars 2011 21:57, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

Ca dépote … ça décape … ça déglingue … ça déchire !!

J’ai volontairement remis les mails originaux ci-dessous pour un historique complet.
D’ailleurs, ton explication par mail était nickel … elle a sa place dans le blog smellup non ? (j’y ai pas trouvé d’équivalent …).

Oui, je l’ai mis en lieu sur pour m’en servir lors d’une prochaine publication sur la Taverne ou Contrib.

Bon, j’ai évidemment quelques petites remarques (on s’refait pas) :

concernant le squelette : en page publique ‹ plugin.html ›, les entrées du tableau d’informations du plugin ne sont pas passées par « propre » ({les liens apparaissent entre crochets pour les lignes ‹ Auteur › et ‹ Licence › notamment}),

Absolument, en fait, j’ai un peu le cul entre deux chaises sur ce sujet en attendant la nouvelle DTD des plugins. Donc ça préfigure plus cette prochaine évolution mais tu as raison je vais finir une version propre avec |propre donc.
En outre, les pages SVP sont plus du « proof of concept » ou du débug sachant que le but est de reprendre le site plugins.spip.net avec SVP uniquement en automatique.

en partie privée, j’ai été un peu dérouté de ne plus retrouver l’éternelle liste des plugins en téléchargement, par contre le formulaire de recherche est super … peut-être pourrait-il être proposé en plus, sans forcément remplacer la liste existante, qui a l’avantage de permettre une mise à jour rapide si on sait de quel plugin il s’agit,

Euh oui on m’a déjà fait la remarque. En fait, j’hésite pour deux raisons :

quelle liste proposer ? si on a des centaines de plugins ça devient pas très illisible je trouve. Et donc quels critères par défaut ? Je me disais que si on vient dans cette liste c’est pas pour chercher en scrollant mais avec le formulaire non ?
performance de l’affichage par défaut.

Sinon l’idée est de combiner SVP et STEP pour refaire l’admin des plugins comme proposé dans l’article http://blog.smellup.net/spip.php?article10

plus quelques fautes d’orthographes sans importance

Arf j’aime pas ! Tu peux me les donner stp ?

Je me suis demandé au passage quelles infos pouvaient être définies dans le fichier « archivelist.txt » concernant le dépôt (infos type « DockBlocks » en haut) ?? Est-ce que tout tag est inclus au XML ? Peut-on par exemple définir un logo pour le dépôt ?

Les infos sont celles que tu vois dans archivelist.txt de la zone. J’ai décrit ça sur mon blog : http://blog.smellup.net/spip.php?article24
Par contre, tu peux toujours éditer l’objet dépôt dans le privé (en cliquant sur son nom dans la page des dépôts) et modifier certains champs et surtout ajouter un logo !

Sinon j’ai rajouté ton dépôt sur le site de démo avec un logo ;-). Si tu ne souhaites pas que ton dépôt y apparaisse dis le moi je l’enlèverais. Mais je trouve sympa que la démo propose plusieurs dépôts en démonstration.
On voit d’ailleurs que tu as des plugins sans catégorie, c’est mal

++
Eric

Piero_Wbmstr · Mars 25, 2011, 12:52

Salut,

Le 25 mars 2011 à 09:28, Eric a écrit :

en partie privée, j’ai été un peu dérouté de ne plus retrouver l’éternelle liste des plugins en téléchargement, par contre le formulaire de recherche est super … peut-être pourrait-il être proposé en plus, sans forcément remplacer la liste existante, qui a l’avantage de permettre une mise à jour rapide si on sait de quel plugin il s’agit,

Euh oui on m’a déjà fait la remarque. En fait, j’hésite pour deux raisons :

quelle liste proposer ? si on a des centaines de plugins ça devient pas très illisible je trouve. Et donc quels critères par défaut ? Je me disais que si on vient dans cette liste c’est pas pour chercher en scrollant mais avec le formulaire non ?

performance de l’affichage par défaut.

C’est un problème compliqué mais intéressant .
J’ai pu remarquer que STEP propose les deux : il laisse la liste standard intacte et ajoute une nouvelle page … pas la meilleure solution non plus puisque cela duplique les pages pour une même utilité … mais entre les deux plugins, on va bien trouver une solution fonctionnelle et ergonomique non

Sinon l’idée est de combiner SVP et STEP pour refaire l’admin des plugins comme proposé dans l’article http://blog.smellup.net/spip.php?article10

Ok, j’avais pas vu tout ça … les deux fonctionnent vraiment bien, mais font un peu doublon sur certains points.
D’ailleurs, j’ai pu remarquer une erreur à l’install de STEP si SVP est déjà installé : les MAJ des tables ne se font pas, du coup il faut installer d’abord STEP puis SVP.
Et j’ai une erreur SQL à chaque ajout de dépôt avec les deux plugins (pas d’erreur avec seulement SVP).

plus quelques fautes d’orthographes sans importance

Arf j’aime pas ! Tu peux me les donner stp ?

Cf. fichier de langue corrigé en pièce jointe

Je me suis demandé au passage quelles infos pouvaient être définies dans le fichier « archivelist.txt » concernant le dépôt (infos type « DockBlocks » en haut) ?? Est-ce que tout tag est inclus au XML ? Peut-on par exemple définir un logo pour le dépôt ?

Les infos sont celles que tu vois dans archivelist.txt de la zone. J’ai décrit ça sur mon blog : http://blog.smellup.net/spip.php?article24
Par contre, tu peux toujours éditer l’objet dépôt dans le privé (en cliquant sur son nom dans la page des dépôts) et modifier certains champs et surtout ajouter un logo !

J’avais vu la discussion sur les logos des plugins (je soutiens d’ailleurs l’idée d’obliger un nom standard pour chaque logo, c’est tout de même plus clair). Mais puisque les paquets créés sont accessibles par HTTP, le logo pourrait l’être aussi non ? du coup on pourrait ajouter un tag « @logo » dans les infos d’un dépôt ?

On voit d’ailleurs que tu as des plugins sans catégorie, c’est mal

Oups … c’est corrigé

Voilou, encore bravo …
Si vous avez besoin d’aide, ou un truc précis en tête, je participe avec plaisir …
J’ai d’ailleurs une proposition, qui concerne surtout les développeurs ou webmestres : je suis toujours un peu frustré de ne pas avoir de « ChangeLog » digne de ce nom dans les plugins, et de devoir aller sur le journal de trac pour me tenir informé des modifs … je propose donc d’inclure dans SVP un générateur de ChangeLog automatique, qui serait ajouté à chaque paquet.

– PiWi

svp_fr.php (11.9 KB)

Loiseau2nuit · Mars 25, 2011, 1:13

2011/3/25 PieroWbmstr <piero.wbmstr@gmail.com>

J’ai d’ailleurs une proposition, qui concerne surtout les développeurs ou webmestres : je suis toujours un peu frustré de ne pas avoir de « ChangeLog » digne de ce nom dans les plugins, et de devoir aller sur le journal de trac pour me tenir informé des modifs … je propose donc d’inclure dans SVP un générateur de ChangeLog automatique, qui serait ajouté à chaque paquet.

J’avoue que pour ma part j’ai tendance à préféré mais plus par habitude qu’autre chose. Il faut dire qu’afficher un flux des changement avec les diff sur chaque fichier, c’est quand même vachement moins indigeste à lire que les éternels changelog.txt dont j’abandonne la lecture au bout de 3-4 lignes en général.

Ceci dit, pour quelqu’un qui n’a pas la même expérience de trac que nous, ca peut effectivement être une idée…

Etienne

eric_tonton · Mars 25, 2011, 1:34

Yop,

Le 25 mars 2011 13:52, PieroWbmstr <piero.wbmstr@gmail.com> a écrit :

C’est un problème compliqué mais intéressant .
J’ai pu remarquer que STEP propose les deux : il laisse la liste standard intacte et ajoute une nouvelle page … pas la meilleure solution non plus puisque cela duplique les pages pour une même utilité … mais entre les deux plugins, on va bien trouver une solution fonctionnelle et ergonomique non

Euh non je crois qu’on parle pas de la même page.
SVP ne s’occupe que de deux choses :

Ajouter une page « Gérer les dépôts »
Remplacer la page « Ajouter un plugin » par sa propre page avec le formulaire de recherche adéquat. Cette page est vide (hors le formulaire) par défaut et se remplit en fonction de la recherche effectuée. Elle ne donne accès qu’à l’installation d’un plugin non encore installé sur site.

Ok, j’avais pas vu tout ça … les deux fonctionnent vraiment bien, mais font un peu doublon sur certains points.
D’ailleurs, j’ai pu remarquer une erreur à l’install de STEP si SVP est déjà installé : les MAJ des tables ne se font pas, du coup il faut installer d’abord STEP puis SVP.
Et j’ai une erreur SQL à chaque ajout de dépôt avec les deux plugins (pas d’erreur avec seulement SVP).

Non c’est temporaire, on doit adapter STEP pour qu’il s’appuie sur SVP pour la base locale des plugins disponibles. Donc en particulier, STEP ne créera plus les mêmes tables que SVP.
STEP prendra ensuite la main sur les deux autres onglets « Listes des plugins » et « Plugins installés » pour n’en faire qu’une page de gestion des plugins présents sur le site.
STEP gère les plugins déjà présents sur le site, SVP gère la base des plugins disponibles sur les dépôts enregistrés.

J’avais vu la discussion sur les logos des plugins (je soutiens d’ailleurs l’idée d’obliger un nom standard pour chaque logo, c’est tout de même plus clair). Mais puisque les paquets créés sont accessibles par HTTP, le logo pourrait l’être aussi non ? du coup on pourrait ajouter un tag « @logo » dans les infos d’un dépôt ?

Oui mais il faudrait un mécanisme pour l’installer à cet endroit.
J’ai l’impression que la page d’édition est suffisante pour cela non ?

Voilou, encore bravo …
Si vous avez besoin d’aide, ou un truc précis en tête, je participe avec plaisir

Ok, je note merci

…
J’ai d’ailleurs une proposition, qui concerne surtout les développeurs ou webmestres : je suis toujours un peu frustré de ne pas avoir de « ChangeLog » digne de ce nom dans les plugins, et de devoir aller sur le journal de trac pour me tenir informé des modifs … je propose donc d’inclure dans SVP un générateur de ChangeLog automatique, qui serait ajouté à chaque paquet.

Pourquoi, il faudra y penser quand le site plugin.spip.net tournera sous SVP pour évaluer l’intérêt ou pas car les commits seront affichés.
Noté également, ça peut aussi avoir un intérêt quand on fait un update par STEP.

Eric

eric_tonton · Mars 25, 2011, 1:36

La question que je me pose est un changelog de quand à quand ?
Souvent les zips sont regénérés suite à un seul commit.
Autre chose, il faudrait aussi plus de discipline dans la mise à jour du numéro de version pour que cela soit lisible.

++
Eric

Le 25 mars 2011 14:13, L’oiseau2nuit <l.oiseau2nuit@gmail.com> a écrit :

2011/3/25 PieroWbmstr <piero.wbmstr@gmail.com>

J’ai d’ailleurs une proposition, qui concerne surtout les développeurs ou webmestres : je suis toujours un peu frustré de ne pas avoir de « ChangeLog » digne de ce nom dans les plugins, et de devoir aller sur le journal de trac pour me tenir informé des modifs … je propose donc d’inclure dans SVP un générateur de ChangeLog automatique, qui serait ajouté à chaque paquet.

J’avoue que pour ma part j’ai tendance à préféré mais plus par habitude qu’autre chose. Il faut dire qu’afficher un flux des changement avec les diff sur chaque fichier, c’est quand même vachement moins indigeste à lire que les éternels changelog.txt dont j’abandonne la lecture au bout de 3-4 lignes en général.

Ceci dit, pour quelqu’un qui n’a pas la même expérience de trac que nous, ca peut effectivement être une idée…

Etienne

Loiseau2nuit · Mars 25, 2011, 1:58

2011/3/25 Eric <eric@smellup.net>

La question que je me pose est un changelog de quand à quand ?

J’avoue, je ne sais pas dans quelle mesure on pourrait immaginer que trac (ou son équivalent giteux) ajoute automatiquement un txt reprenant les (par exemple) 10 derniers logs de commit (ou 15, ou 20… peut être pas plus ca deviendrait vite imbittable…) juste pour qu’un utilisateur puisse avoir, comme sur contrib, une visu sur l’état d’activité du dev.

Souvent les zips sont regénérés suite à un seul commit.
Autre chose, il faudrait aussi plus de discipline dans la mise à jour du numéro de version pour que cela soit lisible.

Hmmmm… disons que je me demande si le n° de révision ne suffirait pas, ca permettrait à tout le monde parler la même langue à mon avis…

Là où je vois plutôt une discipline à réinstaurer, c’est sur la nature des logs de commit justement, parce que pour un utilisateur lambda, même un peu plus débrouillard que les autres,

« report de [qurante-douze vingt-treize] parce truc(‹ muche ›) ne schlibouzait pas dans MACHIN {‹ chouette ›, ‹ tralala ›, ‹ youp ›} >> Tagada(‹ tsoin ›, tsoin’)… »

ca ne parle à personne… (n’étant pas dev même si utilisateur avancé, c’est vraiment comme ça que je perçois certains commit ou discussions sur les listes à l’heure actuelle, alors un « first time user » …)

Etienne.

Piero_Wbmstr · Mars 25, 2011, 3:29

La discussion continue …

J’ai d’ailleurs une proposition, qui concerne surtout les développeurs ou webmestres : je suis toujours un peu frustré de ne pas avoir de « ChangeLog » digne de ce nom dans les plugins, et de devoir aller sur le journal de trac pour me tenir informé des modifs … je propose donc d’inclure dans SVP un générateur de ChangeLog automatique, qui serait ajouté à chaque paquet.

J’avoue que pour ma part j’ai tendance à préféré mais plus par habitude qu’autre chose. Il faut dire qu’afficher un flux des changement avec les diff sur chaque fichier, c’est quand même vachement moins indigeste à lire que les éternels changelog.txt dont j’abandonne la lecture au bout de 3-4 lignes en général.

=> Trac est effectivement très bien et très clair, mais puisque SVP a vocation à s’adapter à d’autres dépôts que la zone, il me semble intéressant de pouvoir proposer une liste des changements dans le code du plugin … tous les dépôts ne disposent pas d’outil comme Trac
En plus, un changelog n’est évidemment pas une oeuvre intellectuelle à lire de A à Z, mais un outil permettant de cibler l’évolution qui peut poser un problème quelconque lors d’une mise à jour par exemple.

La question que je me pose est un changelog de quand à quand ?

J’avoue, je ne sais pas dans quelle mesure on pourrait immaginer que trac (ou son équivalent giteux) ajoute automatiquement un txt reprenant les (par exemple) 10 derniers logs de commit (ou 15, ou 20… peut être pas plus ca deviendrait vite imbittable…) juste pour qu’un utilisateur puisse avoir, comme sur contrib, une visu sur l’état d’activité du dev.

=> là dessus, on peut reprendre l’idée du ChangeLog simple du code de SPIP … personnellement, je l’utilise souvent (mais je suis peut-être le seul
Etant développeur Linux, j’avoue que je préfère vraiment lire un fichier proposé avec la source, aussi illisible soit-il au premier abord, que devoir aller chercher l’info sur un tracker, quitte à compléter le ChangeLog par le tracker si nécessaire.

Souvent les zips sont regénérés suite à un seul commit.
Autre chose, il faudrait aussi plus de discipline dans la mise à jour du numéro de version pour que cela soit lisible.

Hmmmm… disons que je me demande si le n° de révision ne suffirait pas, ca permettrait à tout le monde parler la même langue à mon avis…
Là où je vois plutôt une discipline à réinstaurer, c’est sur la nature des logs de commit

=> En gros, il faudrait mettre en place des « règles de bonne conduite de développement » définissant :- un modèle de numéro de version : par expérience, et c’est visiblement le plus couramment utilisé, un truc du genre XX.YY.ZZZ avec XX le numéro de branche, YY les évolutions importantes et ZZZ le numéro de dernière révision

quelques rappels pour rendre les logs de commits vraiment pertinents

Sur ce point d’ailleurs :

« report de [qurante-douze vingt-treize] parce truc(‹ muche ›) ne schlibouzait pas dans MACHIN {‹ chouette ›, ‹ tralala ›, ‹ youp ›} >> Tagada(‹ tsoin ›, tsoin’)… »
ca ne parle à personne…

=> je ne suis pas d’accord (enfin, si je comprends bien ce que tu veux dénoncer) : il est important de citer les commits antérieurs en rapport et de cibler un minimum la modif et ce qu’elle change ou corrige

Pour finir, j’entends complètement que pour quelqu’un qui ne développe pas ou peu, ce fichier paraisse inutile, auquel cas il suffit de ne pas le lire
Mais vu que l’idée de SVP est d’ouvrir les développements de plugins SPIP à d’autres dépôts que la zone (idée que je soutiens à fond puisque je développe moi-même certains plugins ailleurs), et donc potentiellement à différents types de dépôts, qui ne s’accompagnent pas obligatoirement d’un tracker, il me semble vraiment pertinent de systématiser au maximum la présence d’un suivi des évolutions.
Je rappelle d’ailleurs que c’est la coutume dans la plupart des dévs (Linux ou autre) …

– Pierre

Loiseau2nuit · Mars 25, 2011, 5:09

2011/3/25 PieroWbmstr <piero.wbmstr@gmail.com>

La discussion continue …

Discussion, ben ouais, elle continue, on est 'dredi et ya pas même un ch’ti bout de troll à se mettre sous la dent alors bon, autant causer intlligent

=> Trac est effectivement très bien et très clair, mais puisque SVP a vocation à s’adapter à d’autres dépôts que la zone, il me semble intéressant de pouvoir proposer une liste des changements dans le code du plugin … tous les dépôts ne disposent pas d’outil comme Trac

Pas faux, mais là on se trouve un peu face à une impasse du coup. Parce que ca obligerait chaque taullier de dépot à mettre en oeuvre un système pour le générer. Alors à moins de rendre la présence d’un changelog.txt obligatoire pour que SVP accepte d’indexer le dépot, là je ne vois pas.
Et si on procède comme cela, bonjour les dégats pour la manière dont chacun va gérer la présence effective du dit-fichier…

En plus, un changelog n’est évidemment pas une oeuvre intellectuelle à lire de A à Z, mais un outil permettant de cibler l’évolution qui peut poser un problème quelconque lors d’une mise à jour par exemple.

Ce que trac fait bien meiux que n’importe quel fichier texte selon moi , mais j’ai peut être l’esprit un peu trop fermé (faut pas m’en vouloir, c’est le week end )

« report de [qurante-douze vingt-treize] parce truc(‹ muche ›) ne schlibouzait pas dans MACHIN {‹ chouette ›, ‹ tralala ›, ‹ youp ›} >> Tagada(‹ tsoin ›, tsoin’)… »
ca ne parle à personne…

=> je ne suis pas d’accord (enfin, si je comprends bien ce que tu veux dénoncer) : il est important de citer les commits antérieurs en rapport et de cibler un minimum la modif et ce qu’elle change ou corrige

Ben ouais mais à la rigueur, un truc aussi technico-pointu que ça a plus ca place dans un commentaire de code selon moi, que dans un changelog visant à expliquer à l’utilisateur ce qui a fondamentalement changé dans son outil/plugin

Ou alors c’est que je me fourvoie complètement dans la nature et la finalité d’un changelog ?

Je rappelle d’ailleurs que c’est la coutume dans la plupart des dévs (Linux ou autre) …

Alors là dessus je suis entièrement d’accord, cela dit j’avoue que le Trac représentait pour moi une manière novatrice (et quand même vachement plus digeste) de le faire. Cela dit, l’un n’empèche certainement pas l’autre (enfin j’espère )

Etienne.

Loiseau2nuit · Mars 25, 2011, 7:10

#Redirect2spip-zone

---------- Forwarded message ----------
From: PieroWbmstr <piero.wbmstr@gmail.com>
Date: 2011/3/25
Subject: Re: [SPIP Zone] RETOUR DE TESTS : Smart-Paquets, traductions, dépôts…
To: L’oiseau2nuit <l.oiseau2nuit@gmail.com>

yo

Le 25 mars 2011 à 18:09, L’oiseau2nuit a écrit :

Ben ouais mais à la rigueur, un truc aussi technico-pointu que ça a plus ca place dans un commentaire de code selon moi, que dans un changelog visant à expliquer à l’utilisateur ce qui a fondamentalement changé dans son outil/plugin

Ou alors c’est que je me fourvoie complètement dans la nature et la finalité d’un changelog ?

Un peu

Un « ChangeLog » dans les développements logiciels est le plus souvent la suite complète et brute des messages de modifications informant du contenu de la modif, de son auteur, de sa référence s’il s’agit d’un développement sous un logiciel de contrôle de version et qui permet de séparer les différentes montées en version (et permet d’ailleurs de les justifier). Il n’a normalement vocation qu’à être utilisé pour et par les développeurs, et représente en gros la seule référence constante des évolutions.
Du coup, dans le cas de la zone spip par exemple, le tracker se charge d’« expliquer à l’utilisateur ce qui a fondamentalement changé dans son outil/plugin » alors que le ChangeLog liste brutalement les modifs du code.

Pour plus d’infos, la nomenclature du projet GNU : http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html (j’ai pas trouvé en français …)

Evidemment, je ne veux rien imposer dans SPIP, ni aux développeurs, ni aux autres, mais il se trouve que j’utilise ce modèle depuis longtemps et que c’est quand même vraiment utile. C’est tellement pratique que je l’impose souvent dans la plupart de mes projets … ça permet de s’y retrouver (cf. http://trac.pierowbmstr.fr/p/arules/page/Changelog/)

[…] ca obligerait chaque taullier de dépot à mettre en oeuvre un système pour le générer. Alors à moins de rendre la présence d’un changelog.txt obligatoire pour que SVP accepte d’indexer le dépot, là je ne vois pas.

Et si on procède comme cela, bonjour les dégats pour la manière dont chacun va gérer la présence effective du dit-fichier…

Là je suis d’accord : il ne faut pas que ce soit obligatoire. En fait, après réflexion, le mieux serait d’ajouter cette possibilité à « smart_paquets » plutôt qu’à un plugin.
Je teste ça et vous tiens au courant.

Bon week-end les spipeurs

– P.