Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça, mais si un tableau regroupait l'ensemble des plugins développé sur la zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est un boulot de romain, mais y a des balaises en script ici, j'aimarais bien savoir si c'est jouable ?
Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça,
mais si un tableau regroupait l'ensemble des plugins développé sur la
zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
un boulot de romain, mais y a des balaises en script ici, j'aimarais
bien savoir si c'est jouable ?
Je sais pas si c’est réaliste d’imaginer un script qui atomatiserait ça,
mais si un tableau regroupait l’ensemble des plugins développé sur la
zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
Je ne dis pas qu’il faut lancer la rédaction du tableau à la main, c’est
un boulot de romain, mais y a des balaises en script ici, j’aimarais
bien savoir si c’est jouable ?
Je pense que c’est jouable
Je joins un script en ce sens
je le lance dans le répertoire où se trouve les plugins c’est à dire où je viens d’exécuter la commande
svn checkout svn://zone.spip.org/spip-zone/plugins .
Ensuite tu rends exécutable le script que je fournis tableauplugin.pl (script fait en perl tournant sous linux)
Il crée alors un fichier
tableaurecapilulatif.html
Qui est le tableau rrécapitulatif des plugins et de leur état et de la localisation
Je joins aussi le résultat que j’obtiens à ce mail
C’est un premier jet on peut rajouter pas mal de truc ( genre trier par état stable, dev, expérimentale)
Ce serait cool d'avoir un lien vers une page du wiki sur laquelle on
mettrait la doc du plugin. Genre PluginSpip+nom_du_plugin.. Qu'en
dites-vous ?
2006/8/30, job job <rudjob@gmail.com>:
Le 30/08/06, James <james@rezo.net> a écrit :
> Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça,
> mais si un tableau regroupait l'ensemble des plugins développé sur la
> zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
>
> Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
> un boulot de romain, mais y a des balaises en script ici, j'aimarais
> bien savoir si c'est jouable ?
Je pense que c'est jouable
Je joins un script en ce sens
je le lance dans le répertoire où se trouve les plugins c'est à dire où je
viens d'exécuter la commande
svn checkout svn://zone.spip.org/spip-zone/_plugins_ .
Ensuite tu rends exécutable le script que je fournis tableauplugin.pl
(script fait en perl tournant sous linux)
Il crée alors un fichier
tableaurecapilulatif.html
Qui est le tableau rrécapitulatif des plugins et de leur état et de la
localisation
Je joins aussi le résultat que j'obtiens à ce mail
C'est un premier jet on peut rajouter pas mal de truc ( genre trier par état
stable, dev, expérimentale)
Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça,
mais si un tableau regroupait l'ensemble des plugins développé sur la
zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
un boulot de romain, mais y a des balaises en script ici, j'aimarais
bien savoir si c'est jouable ?
Je pense que c'est jouable
Je joins un script en ce sens
je le lance dans le répertoire où se trouve les plugins c'est à dire où je
viens d'exécuter la commande
svn checkout svn://zone.spip.org/spip-zone/_plugins_ .
Ensuite tu rends exécutable le script que je fournis
tableauplugin.pl(script fait en perl tournant sous linux)
Il crée alors un fichier
tableaurecapilulatif.html
super !
Qui est le tableau rrécapitulatif des plugins et de leur état et de la
localisation
Je joins aussi le résultat que j'obtiens à ce mail
bonne idée de rajouter la localisation
C'est un premier jet on peut rajouter pas mal de truc ( genre trier par état
stable, dev, expérimentale)
ça me semble primordial, avec 'dev' par défaut si la mention n'est pas présente.
Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça,
mais si un tableau regroupait l'ensemble des plugins développé sur la
zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
un boulot de romain, mais y a des balaises en script ici, j'aimarais
bien savoir si c'est jouable ?
Il n'y a rien d'inimaginable ... surtout par exemple pour les plugins avec le xml où il y a déjà 2 ou 3 renseignements , mais on doit pouvoir "récupérer" pas mal de chose.
D'ailleurs ça serait vraiement bien si on pouvait avoir une correspondance des versions mini/maxi du core avec lesquelles le plugin est (supposé) compatible (un ajout dans plugin.xml ?)
Ca pourrait plus ou moins se coupler avec la génération des paquets dont on causait par ailleurs.
D'ailleurs , le boulot de romain c'est ni fiable ni durable
--
toggg
PS. J'étais parti croquer un bout de pizza entre temps et Job a posé son truc ... j'envoie quand même
tu as un compte sur la zone ?
tu le déposes là ? Connexion · GitLab
(ou ailleurs)
On 8/30/06, job job <rudjob@gmail.com> wrote:
Le 30/08/06, James <james@rezo.net> a écrit :
> Je sais pas si c'est réaliste d'imaginer un script qui atomatiserait ça,
> mais si un tableau regroupait l'ensemble des plugins développé sur la
> zone avec leurs noms, versions, prefix et états, ce serait un outil utile.
>
> Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
> un boulot de romain, mais y a des balaises en script ici, j'aimarais
> bien savoir si c'est jouable ?
Je pense que c'est jouable
Je joins un script en ce sens
je le lance dans le répertoire où se trouve les plugins c'est à dire où je
viens d'exécuter la commande
svn checkout svn://zone.spip.org/spip-zone/_plugins_ .
Ensuite tu rends exécutable le script que je fournis tableauplugin.pl
(script fait en perl tournant sous linux)
Il crée alors un fichier
tableaurecapilulatif.html
Qui est le tableau rrécapitulatif des plugins et de leur état et de la
localisation
Je joins aussi le résultat que j'obtiens à ce mail
C'est un premier jet on peut rajouter pas mal de truc ( genre trier par état
stable, dev, expérimentale)
Ce serait cool d'avoir un lien vers une page du wiki sur laquelle on
mettrait la doc du plugin. Genre PluginSpip+nom_du_plugin.. Qu'en
dites-vous ?
Est-ce que tu peux faire quelquechose au niveau de trac pour faire un cron du script de job ? Est-ce que c'est facile de mettre à jour une page du wiki en ligne de commande, depuis un script ?
Je ne dis pas qu’il faut lancer la rédaction du tableau à la main, c’est
un boulot de romain, mais y a des balaises en script ici, j’aimarais
bien savoir si c’est jouable ?
Il n’y a rien d’inimaginable … surtout par exemple pour les plugins
avec le xml où il y a déjà 2 ou 3 renseignements , mais on doit pouvoir
« récupérer » pas mal de chose.
D’ailleurs ça serait vraiement bien si on pouvait avoir une
correspondance des versions mini/maxi du core avec lesquelles le plugin
est (supposé) compatible (un ajout dans plugin.xml ?)
Entièrement d’accord avec Bertrand, le script que je viens de faire ne fait que rechercher la balise dans le fichier plugin.xml, donc si nécessaire on peut extraire d’autre information.
De plus j’ai une remarque
Dans plugin.xml
Il y a 2 types d’écritures
soit stable
soit
stable
Ce serait bien s’il y avait une uniformisation des écritures et sincèrement je préfère la seconde
A+
Job
Entièrement d'accord avec Bertrand, le script que je viens de faire ne fait
que rechercher la balise <etat> dans le fichier plugin.xml, donc si
nécessaire on peut extraire d'autre information.
De plus j'ai une remarque
Dans plugin.xml
Il y a 2 types d'écritures
soit <etat>stable</etat>
soit
<etat>
stable
</etat>
Ce serait bien s'il y avait une uniformisation des écritures et sincèrement
je préfère la seconde
A+
Job
mea culpa, j'aime bien la première pour son style dense
mais qu'à cela ne tienne, je changerai mes habitudes si on ne peut pas "trimmer" une chaîne en perl
Gilles Vincent a écrit :
> Ce serait cool d'avoir un lien vers une page du wiki sur laquelle on
> mettrait la doc du plugin. Genre PluginSpip+nom_du_plugin.. Qu'en
> dites-vous ?
>
Est-ce que tu peux faire quelquechose au niveau de trac pour faire un
cron du script de job ? Est-ce que c'est facile de mettre à jour une
page du wiki en ligne de commande, depuis un script ?
Heu, je voulais juste dire que si on met dans le tableau un lien ayant
2 majuscules, celle-ci existe déjà virtuellement dans le wiki :
le premier qui se pointera sur cette page pourra la créer (s'il est
connecté bien sûr) et mettre des infos sur le plugin en question.
En parallele, il suffit de renommer les pages décrivant actuellement
les plugins, pour qu'elles correspondent a la dénomination
PluginSpip_nomDuPlugin.
Comme ça tout est cablé.. du côté du wiki et du côté du tableau [qu'on
va bientôt transformer en modèle Spip, je le sens ]
> Je ne dis pas qu'il faut lancer la rédaction du tableau à la main, c'est
> un boulot de romain, mais y a des balaises en script ici, j'aimarais
> bien savoir si c'est jouable ?
>
Il n'y a rien d'inimaginable ... surtout par exemple pour les plugins
avec le xml où il y a déjà 2 ou 3 renseignements , mais on doit pouvoir
"récupérer" pas mal de chose.
D'ailleurs ça serait vraiement bien si on pouvait avoir une
correspondance des versions mini/maxi du core avec lesquelles le plugin
est (supposé) compatible (un ajout dans plugin.xml ?)
C'est pas bête comme idée, reste à trouver la notation. On peut aussi penser à un système de dépendance entre plugin, où c'est trop lourd ?
Entièrement d'accord avec Bertrand, le script que je viens de faire ne fait
que rechercher la balise <etat> dans le fichier plugin.xml, donc si
nécessaire on peut extraire d'autre information.
le <prefix>. Ainsi, on pourra (au moins pour la zone) s'assurer avant commit qu'un plugin n'utlise pas le préfixe d'un autre.
Entièrement d'accord avec Bertrand, le script que je viens de faire ne fait
que rechercher la balise <etat> dans le fichier plugin.xml, donc si
nécessaire on peut extraire d'autre information.
De plus j'ai une remarque
Dans plugin.xml
Il y a 2 types d'écritures
soit <etat>stable</etat>
soit
<etat>
stable
</etat>
Ce serait bien s'il y avait une uniformisation des écritures et sincèrement
je préfère la seconde
A+
Job
mea culpa, j'aime bien la première pour son style dense
mais qu'à cela ne tienne, je changerai mes habitudes si on ne peut pas "trimmer" une chaîne en perl
Je ne pense pas qu'on puisse imposer un style , tant que c'est conforme xml , c'est à l'utilitaire de s'adapter , sachant qu'il devra bien sûr trimmer les valeurs
Super !
Je m'interroge simplement sur l'utilisation du perl , non pas que je n'aime pas le langage mais sur le fait qu'il restreint le public à même d'y mettre le nez. Je dis ça , mais je livre du bash , hein !
On est quand même chez spiPHP !
On devrait peut-être , si applicable , systématiquement utiliser PHP pour ce genre d'utilitaire.
Ne serait-ce que si on veut les intégrer dans une application.
J'ai aussi une pensée émue pour ceux du tiers-monde megahard ... il y a sans doute plus de chance qu'ils aient php installé que perl ou ... bash
à+
--
toggg
Je m’interroge simplement sur l’utilisation du perl , non pas que je
n’aime pas le langage mais sur le fait qu’il restreint le public à même
d’y mettre le nez. Je dis ça , mais je livre du bash , hein !
On est quand même chez spiPHP !
On devrait peut-être , si applicable , systématiquement utiliser PHP
pour ce genre d’utilitaire.
Très juste, c’était un premier jet juste pour répondre à la question est-ce jouable.
Il fallait une preuve, donc j’ai utilisé le language de script que je connais le mieux
Mais effectivement il est tout à fait préférable de le passer en php (chose que je suis en train d’essayer de faire) mais je maitrise moins bien ce language
Ne serait-ce que si on veut les intégrer dans une application.
J’ai aussi une pensée émue pour ceux du tiers-monde megahard
Comme le tiers-etat avant la révolution, le tiers monde informatique (M$) représente 95% de la population
… il y a
sans doute plus de chance qu’ils aient php installé que perl ou … bash
à+