[message long :-)]
Salut à tous,
Au fur et à mesure que le développement de Ncooker avance, le gestionnaire de
messages qu'il utilise commence à montrer ses limites :-), et je vous propose
d'y apporter quelques modifications.
Ce gestionnaire de messages propose 3 niveaux de « verbosité » successifs
nommés INFO, DETAIL et FULL (je ne parle pas des niveaux ERROR et WARNING qui
sont des niveaux un peu spéciaux utilisés en combinaison avec le gestionnaire
d'erreurs).
L'utilisateur choisit la « quantité » de messages qu'il veut voir affiché à
l'écran en utilisant l'option -v de Ncooker. Par exemple :
$ Ncooker -v DETAIL <command>
Pour le développeur, la fonction print_msg permet d'afficher un message pour
l'un des niveaux disponibles. Par exemple :
print_msg "INFO" "Ce message est affiché si le niveau de verbosité est au
minimum INFO."
print_msg "DETAIL" "Ce message est affiché si le niveau de verbosité est au
minimum DETAIL."
print_msg "FULL" "Ce message est affiché si le niveau de verbosité est au
minimum FULL."
Chaque niveau applique éventuellement à ses messages une « indentation »
permettant de mieux visualiser les différents degrés de détails. Ainsi, les
messages du niveau INFO n'ont pas d'indentation, ceux du niveau DETAIL ont
une indentation de 4 espaces et ceux de FULL ont 8 espaces.
Maintenant, voici quelques exemples montrant les limites que je rencontre :
* Imaginons que lorsqu'on lance la commande « Ncooker pack working_dir », je
veuille afficher les messages suivants :
Creation of the working_dir package ...
Checking working_dir directory content ...
Checking infos file ...
Getting file content ...
Checking syntax ...
Checking NPKG_VERSION variable ...
Checking NPKG_RELEASE variable ...
<...>
Checking build file ...
Getting file content ...
Checking syntax ...
Checking do_preconfig function ...
Checking do_config function ...
<...>
Checking desc file ...
<...>
Checking changelog file ...
<...>
Preparing packaging environment ...
Creating working directory ...
Copying configuration files ...
Adding computed informations to "infos" file ...
Adding archives checksums ...
Adding package author ...
Adding creation informations to "changelog" file ...
Create "working_dir" NBUILD package ...
Cleaning packaging environment ...
Ceux qui ont déjà utilisé la dernière version de développement de Ncooker
verront que ce n'est pas tout à fait ce qu'affiche la commande pack actuelle,
notamment pour ce qui est du premier message. Mais cet exemple est justement
ce que j'aimerais obtenir :-)
Une fois que ces messages sont codés dans les différents modules de Ncooker,
on obtient ceci :
$ Ncooker -v INFO pack working_dir
Creation of the working_dir package ... [ OK ]
$ Ncooker -v DETAIL pack working_dir
Creation of the working_dir package ...
Checking working_dir directory content ... [ OK ]
Preparing packaging environment ... [ OK ]
Create "working_dir" NBUILD package ... [ OK ]
Cleaning packaging environment ... [ OK ]
$ Ncooker -v FULL pack working_dir
Creation of the working_dir package ...
Checking working_dir directory content ...
Checking infos file ... [ OK ]
Checking build file ... [ OK ]
Checking desc file ... [ OK ]
Checking changelog file ... [ OK ]
Preparing packaging environment ...
Creating working directory ... [ OK ]
Copying configuration files ... [ OK ]
Adding computed informations to "infos" file ... [ OK ]
Adding creation informations to "changelog" file ... [ OK ]
Create "working_dir" NBUILD package ... [ OK ]
Cleaning packaging environment ... [ OK ]
Et là, on a utilisé tous les niveaux possibles du gestionnaire de messages :-)
J'ai dit que tous les messages précédents étaient codés, mais en réalité, on
ne peut pas coder plus de trois niveaux de messages. Et donc, tous les
messages de niveau « 4 » de mon exemple n'existent pas. Le problème est donc
qu'il n'y a pas suffisamment de niveaux de verbosité.
Comme solution à ce problème, je propose d'abandonner le nommage des niveaux
INFO, DETAIL et FULL pour utiliser à la place des niveaux numérotés de 1 à N,
"N" étant « théoriquement » infini, mais dans la pratique, il faudra se
limiter à un nombre de niveaux raisonnable :-). Les développeurs utiliserait
print_msg de cette manière :
print_msg 1 "ce message est affiché si le niveau de verbosité est au minimum
1"
print_msg 2 "ce message est affiché si le niveau de verbosité est au minimum
2"
print_msg 3 "ce message est affiché si le niveau de verbosité est au minimum
3"
print_msg 4 "ce message est affiché si le niveau de verbosité est au minimum
4"
...
Le niveau de verbosité serait toujours sélectionné de la même façon, mais en
indiquant un nombre :
Ncooker -v 1 <command>
Ncooker -v 2 <command>
Ncooker -v 3 <command>
Ncooker -v 4 <command>
...
(Les niveaux QUIET, ERROR et WARNING seraient néanmoins conservés, et la liste
complète des niveaux de verbosité successifs serait QUIET, ERROR, WARNING, 1,
2, 3, 4, ... N)
Chaque niveau appliquerait à ses messages une indentation correspondant à son
degré de détail.
* Autre problème rencontré : dans mon exemple précédent, j'utilise la commande
pack. Mais tous les messages ne sont pas affichés uniquement par cette
commande. En fait, le code de la commande pack se présente ainsi :
print_msg "INFO" "Creation of the ${dir} package ..."
run_command check ${dir}
print_msg "DETAIL" "Preparing packaging environment ..."
<...>
On voit que le premier message est affiché par la commande Pack, mais que ceux
qui suivent sont affichés par la commande Check de Ncooker. Puis, lorsque la
commande Check se termine, la commande Pack continue à afficher ses propres
messages.
Pour que l'affichage des messages se présente correctement à l'écran, il faut
que la commande Check commence au niveau "DETAIL" de verbosité :
print_msg "DETAIL" "Checking ${dir} directory content ..."
print_msg "FULL" "Checking infos file ..."
<...>
en procédant ainsi, l'enchevêtrement des messages des commandes Pack et Check
passe inaperçu grâce à une indentation correcte.
Le problème est que la commande Check n'est pas utilisée que par la commande
Pack. Elle peut également être lancée à partir de la ligne de commande. Et
comme les messages affichés ne commencent qu'au niveau DETAIL, l'utilisateur
qui fait :
$ NCooker -v INFO check <paquet>
ne verra aucun message s'afficher ! :-)
Pour bien faire, il faudrait que la commande Check commence l'affichage de ses
messages au niveau INFO, mais dans ce cas, le problème se déplace au niveau
de son utilisation par la commande Pack.
Cet exemple montre le cas particulier de la commande Check par Pack, mais ce
problème peut se poser avec tout autre commande/module utilisé par une autre
commande/module.
Je propose une solution qui repose sur la solution précédente (niveau de 1
N). L'idée est que les développeurs n'aient plus à se prendre la tête pour
savoir à quel niveau de verbosité ils doivent commencer l'affichage de leurs
messages selon que leur module est appelé en ligne de commande ou par un
autre module : ce serait _toujours_ le niveau 1.
Ensuite, je propose d'ajouter deux nouvelles fonctions au gestionnaire de
messages : shiftMsgLevel() et unshiftMsgLevel(). Elles seraient utilisés pour
appliquer et annuler un décalage dans les niveaux de verbosité des messages.
Par exemple :
Commande Pack :
print_msg 1 "Creation of the ${dir} package ..."
shiftMsgLevel
run_command check ${dir}
unshiftMsgLevel
print_msg 2 "Preparing packaging environment ..."
<...>
Commande Check :
print_msg 1 "Checking ${dir} directory content ..."
print_msg 2 "Checking infos file ..."
<...>
La commande Pack affiche son message de niveau 1. Puis elle appelle
shiftMsgLevel() pour appliquer un décalage de niveau pour les prochains
messages. La « quantité » de décalage correspondrait au niveau du dernier
message affiché par print_msg, donc ici 1.
Lorsque la commande Check va afficher son premier message de niveau 1, la
fonction print_msg va appliquer ce décalage de « 1 », ce qui fait que le
premier message de check va devenir un message de niveau 2, et donc avoir une
indentation plus importante. Il va se passer la même chose pour le second
message de Check, qui va passer du niveau 2 au niveau 3.
Une fois que la commande Check est terminé, on revient dans la commande pack
pour exécuter la fonction unshiftMsgLevel afin d'annuler le décalage demandé
précédemment. Ainsi, les message suivants de Pack s'afficheront avec le
niveau correct.
Les appels successifs de la fonction shiftMsgLevel permettrait d'accumuler les
décalages, c'est-à-dire que que si la commande Check fait appel à un autre
module et qu'un décalage à déjà lieu, le nouvel appel à shiftMsgLevel
appliquera un nouveau décalage en tenant compte du décalage actuel. De la
même manière, la fonction unshiftMsgLevel permettrait de revenir aux
décalages précédents de manière successive.
Voilà le principe :-)
Je pense que ces solutions permettent de rendre le gestionnaire de messages
plus souple et plus pratique. Dites-moi ce que vous en pensez.
++
Gontran
