Un hack vraiment sale pour contourner le log de YunoHost pour les commandes en conditionnel.
Autrement, la commande log une erreur dans son log et est considérée comme une commande échouée par l'intégration continue.
Le fruit d'une longue discussion stérile:
>(14:01:23) Maniack C: @Bram, tu sais comment sont gérés les sorties d'erreurs des commandes YunoHost, par rapport au log?
(14:01:44) Bram: Maniack C: il va falloir que tu détails ta question
(14:02:27) Maniack C: Les commandes ynh en cli log dans le fichier de log, mais si on redirige la sortie des commandes dans /dev/null, elles log toujours de la même manière
(14:03:11) Maniack C: On dirait qu'on a aucun contrôle sur le log des commandes
(14:04:13) Maniack C: Est-ce que l'argument --quiet change se comportement?
(14:05:00) Bram: je ne sais pas
(14:05:22) Bram: si les commandes loguent dans un fichier, rediriger l'output ne changera rien
(14:05:41) Maniack C: Oui remarque c'est évident...
(14:05:43) Bram: rediriger l'output ça change uniquement les fd stdout/stderr
(14:08:18) Maniack C: Hum, et quiet coupe juste la sortie standard
(14:08:27) Maniack C: C'est un peu inutile du coup
(14:20:47) Maniack C: Je ne trouve --quiet que dans une branche du code... Et là il vire seulement tty
(14:20:57) Bram: Maniack C: tu veux faire quoi en fait ?
(14:21:17) Maniack C: Trouver ce que fait --quiet et pourquoi
(14:21:33) Maniack C: Dans le fond surtout, supprimer toute sortie d'une commande
(14:21:44) Maniack C: Pour les usages en if ou while
(14:21:46) Bram: pourquoi tu veux faire ça ?
(14:21:57) Maniack C: Ça provoque des erreurs
(14:22:13) Bram: mais encore ?
(14:22:36) Maniack C: typiquement ça:
while ! sudo yunohost app checkport $port ; do
port=$(($port + 1))
done
(14:22:45) Maniack C: La commande sort une erreur
(14:23:04) Maniack C: Alors qu'on voudrait juste tester le résultat de la commande
(14:23:46) Maniack C: Et le quiet ou le /dev/null te fait juste croire qu'il n'y a pas d'erreur
(14:23:55) Bram: et ça devrait faire quoi exactement ?
(14:24:01) Bram: (on va finir par y arriver :p)
(14:24:04) Bram: #xyproblem
(14:24:56) Maniack C: Ba quand tu testes une commande en if, tu élude la sortie d'erreur et tu test juste la sortie de commande
(14:25:06) Maniack C: Et aucune erreur n'est affichée
(14:25:15) Maniack C: Là on a quand même une erreur dans le log
(14:25:32) Bram: tu testerais pas le code de retour ?
(14:25:33) Maniack C: Résultat en intégration continue, l'app est cassée
(14:25:40) Bram: sinon en vrai tu veux une commande pour avoir un port libre, c'est ça ?
(14:25:45) Maniack C: C'est le cas dans ce while
(14:26:23) Maniack C: Oui, mais scith a eu le même problème avec ynh_app_setting_get
(14:26:56) Bram: ça ressemble surtout à des commandes mal foutu
(14:27:06) Bram: et vous devriez plutôt en parler que chercher des hacks en bash :/
(14:27:08) Maniack C: Le problème est qu'on ne peut pas rendre la commande vraiment silencieuse
(14:27:49) Maniack C: Pour tester la sortie de commande, il n'y a pas beaucoup de solution
(14:27:55) Maniack C: Il faut l'éxecuter
(14:28:36) Maniack C: Mais quand on fait ça, on rend la commande silencieuse pour utiliser uniquement son code de sortie
(14:28:58) Bram: tu peux utiliser $?
(14:29:03) Bram: pour choper uniquement le code de sortie
(14:29:09) Bram: au lieu de l'output
(14:29:32) Maniack C: Le problème c'est que la commande log une erreur quoi qu'il en soit
(14:29:56) Maniack C: Indépendemment de sa sortie, le while travaille sur le code de sortie, ça pose pas de problème ça
(14:30:13) Maniack C: Mais elle log toujours une erreur
(14:31:55) Bram: hm
(14:31:57) Bram: si je comprend bien
(14:32:04) Bram: la commande produit pas le bon code d'erreur quand elle devrait
(14:32:05) Bram: c'est ça ?
(14:32:10) Maniack C: non
(14:32:10) Bram: si oui
(14:32:20) Bram: alors je capte pas pourquoi le fait qu'elle log est un problème
(14:32:47) Maniack C: Parce que derrière c'est le log qui est analysé pour vérifier si tout c'est bien passé
(14:32:59) Bram: et pourquoi vous analysez pas le code de sortie ?
(14:33:37) Maniack C: > (14:25:33) Maniack C: Résultat en intégration continue, l'app est cassée
(14:33:44) Bram: arf
(14:33:46) Maniack C: Le problème se répercute ici
(14:33:58) Maniack C: C'est le log complet qui est analysé
(14:33:58) Bram: ouais donc faudrait bien plutôt des commandes qui marchent comme prévu quoi
(14:34:10) Maniack C: Car c'est le seul à être vraiment comlet
(14:35:11) Maniack C: Ben faudrait pouvoir faire un quiet complet
(14:35:23) Maniack C: Pour n'avoir aucune sortie quand c'est nécessaire
(14:35:45) Bram: mouais, ça ressemble vraiment à un gros hack vu d'ici
(14:36:20) Maniack C: Le problème c'est que la commande, tu peux bien l'appeler comme tu veux, elle sort toujours une erreur dans son log avant de donner la main au shell parent
(14:36:37) Maniack C: Donc on peut pas la faire taire
(14:36:46) Maniack C: Pas depuis le shell du moins
(14:37:07) Bram: ça me semble un comportement pas déconnant franchement
(14:37:34) Maniack C: Disons que le problème c'est qu'il nous faudrait un -qq au lieu d'un simple -q
(14:37:42) Maniack C: Le quiet ne fait que couper stdout
(14:37:57) Maniack C: Ce qu'on pourrait tout aussi bien faire côté shell
(14:38:48) Maniack C: --quietlog par exemple nous serait utile pour rendre la commande vraiment silencieuse quand on veut l'utiliser en if
(14:42:47) Maniack C: Et je trouve pas l'argument dans le code...
(14:42:56) Bram: je pense pas que ça soit prévu
(14:43:05) Bram: ce qui me semble logique d'un point de vue dev hein
(14:43:14) Maniack C: Non c'est pas prévu
(14:43:15) Bram: y a jamais un moment où un dev va vouloir faire ça pour son soft
(14:43:28) Maniack C: Ben si, tu as ça avec d'autres commandes
(14:43:36) Maniack C: Aucune sortie
(14:43:42) Bram: oui mais là on parle de logs
(14:43:46) Bram: c'est pas pareil qu'une sortie
(14:44:01) Maniack C: Du coup ça bloque le CI cette histoire
(14:44:04) Bram: surtout quand t'as un service qui tourne, refuser de loguer ça me semble pas logique
(14:44:52) Bram: si tu veux vraiment empêcher de loger tu peux bouger le fichier de log avant de lancer la commande
(14:45:07) Maniack C: Là c'est un cas isolé où on veut aucune sortie pour tester une commande
(14:45:14) Bram: mais je continue de penser que cette approche de "pas logger" est une mauvaise approche à un vrai problème
(14:45:49) Maniack C: Le problème c'est que là ça empêche d'utiliser des commandes yunohost en test dans les scripts
(14:45:53) Bram: ben si c'est un cas isolé faut vraiment pas modifier un comportement globale pour ça mais analyser le cas et y apporter une solution spécifique
(14:46:12) Maniack C: C'est pour ça que je pense à un argument comme --quiet
(14:46:25) Maniack C: Puisque qu'en shell on peut rien faire
(14:54:43) Maniack C: Sans modifier --quiet, on pourrait simplement ajouter un argument avec handlers.remove('file')
(14:56:28) Bram: je continue de penser que tu dois lister les cas où ça pose problèmes et qu'on doit les analyser pour voir comment les résoudre plutôt que de faire un gros hack hein
(14:56:34) Bram: mais bon, t'as pas l'air de vouloir entendre ça :p
(14:56:50) Maniack C: Ben les cas c'est tout les if et les while
(14:57:11) Maniack C: Car ils vont potentiellement sortir en erreur
(14:57:18) Bram: ben liste tous les if et while où t'as besoin de faire ça
(14:57:33) Bram: là par exemple y a le fait qu'il faut une commande pour trouver un port libre qui génère pas d'erreur
(14:57:39) Bram: je veux voir quels sont les autres cas
(14:57:50) Maniack C: Plus on encourage l'usage des helpers, plus on créer ces situations !
(14:58:04) Maniack C: Jusqu'à présent on codait tous nos propres solutions
(14:58:17) Maniack C: Mais attend, j'en ai sous le coude moi
(15:00:31) Maniack C: https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L97https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L125https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L133https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L209
(15:00:40) Maniack C: Et j'utilise peu de helpers
(15:01:11) Maniack C: Plus on encourage leur usage, plus on va créer des situations où ils seront conditionnés
(15:02:29) Maniack C: On peut toujours les contourner bien sûr
C'est le cas ici:
https://github.com/YunoHost-Apps/nextcloud_ynh/pull/12/files#diff-44cb16c778719320333118c04d509a7cR17
(15:03:00) Maniack C: Mais on régresse par rapport à l'encouragement à l'usage des helpers
(15:05:43) Maniack C: Josue-T pour son app monitorix je peux lui dire de ne pas utiliser sudo yunohost app checkport pour qu'elle fonctionne correctement.
Mais ça me semble aller à l 'encontre de l'idée des helpers
(15:07:44) Bram: ben c'est pas un problème de son app hein
(15:07:53) Bram: c'est un problème au niveau CI/yunohost donc lui a rien a changer
(15:08:27) Maniack C: Pour nextcloud j'ai changé mon code, car c'était simple à faire pour éviter ça
(15:09:13) Bram: le problème c'est que ces commandes ont pas été pensés pour être utilisé dans ton cas
(15:09:22) Maniack C: Je comprend bien
(15:09:30) Bram: c'est des commandes qui sont pensés pour utilisateur alors que tu t'en sers comme des briques de programmation
(15:09:36) Bram: ce qui est logique remarque vu les commandes
(15:09:38) Maniack C: Mais de fait on les utilises de plus en plus comme ça
(15:09:56) Bram: ça revient aussi à la volonté de jérôme de virer ça du code de yunohost
(15:10:09) Maniack C: Alors en l'occurrence Josue-T à pris mon code, mais je suis pas le seul
(15:10:59) Bram: j'ai le même problème dans mon code pour les settings globals
(15:11:14) Bram: je sais pas comment retourner un code système 1/0 pour que ça soit utilisé programmatiquement
(15:11:41) Maniack C: Là on l'a ce code de sortie sur ces commandes
(15:11:55) Bram: ouais mais ce code est généré par le logger
(15:12:01) Bram: qui fait les messages qui t'emmerdent
(15:12:07) Maniack C: ah ok
(15:12:09) Bram: https://github.com/YunoHost/yunohost/blob/unstable/src/yunohost/app.py#L882
(15:12:43) Bram: le problème c'est le mélange entre ces commandes utilisateurs
(15:12:49) Bram: et des commandes pour de la programmation
(15:12:55) Bram: jérôme a tenté de foutre ça dans des helpers
(15:13:07) Bram: mais c'est un peu mettre un pansement sur le problème
(15:13:16) Bram: faudrait idéalement un yunocode $stuff
(15:13:25) Bram: qui soit autre chose que la commande yunohost
(15:13:58) Bram: (d'ailleurs la commande check_port est méga bancale)
(15:14:40) Maniack C: Donc en somme il ne faudrait pas utiliser la moulinette CLI pour les helpers?
(15:14:55) Bram: idéalement oui
(15:15:09) Maniack C: Difficile à justifier pour qui n'a pas le nez dedans
(15:15:18) Bram: oui enfin
(15:15:20) Bram: là je te dis "idéalement"
(15:15:26) Bram: c'est un problème de design
(15:15:30) Bram: on a pas de solution sous la main
(15:15:45) Bram: donc aujourd'hui utiliser la moulinette dans les helpers est tout à fait raisonable
(15:15:52) Bram: mais ça pose les problèmes que tu as
(15:15:56) Maniack C: C'est que les commandes cli, yunohost ou autre, sont habituellement utiliser en shell
(15:16:36) Maniack C: A mon avis, si tu dis à un nouvel utilisateur qu'il ne doit pas scripter des commandes Yunohost, il ne comprendra pas
(15:16:54) Bram: ça sera un dev hein
(15:16:57) Bram: pas un utilisateur
(15:17:02) Maniack C: Certes oui
(15:17:03) Bram: et il aura théoriquement un manuel avec les helpers
(15:17:17) Bram: on devrait pas avoir de "check_port" dans les commandes yunohost par exemple
(15:17:48) Maniack C: Mais je crois que beaucoup de helpers utilisent la moulinette en fin de compte
(15:18:00) Bram: ben oui, c'est normal
(15:18:01) Bram: y a que ça
(15:18:50) Maniack C: Bon en somme, ma meilleur chance reste encore de réécrire un helper pour remplacer cette commande
(15:18:53) Maniack C: Ou pire...
(15:19:04) Maniack C: Un helper "hack dégueux" pour niquer le log...
(15:19:21) Bram: à très court terme oui
(15:19:27) Bram: à moyen terme il faudrait qu'on bosse sur ça
(15:19:39) Bram: pour qu'il y a des opérations bas niveau disponible qui fassent ce dont tu as besoin
(15:19:56) Maniack C: C'est si difficile en python de sortir le code d'erreur indépendemment?
(15:19:59) Maniack C: (vrai question)
(15:20:05) Bram: non, c'est trivial
(15:20:13) Bram: sys.exit(code)
(15:20:20) Maniack C: En effet
(15:20:25) Bram: là c'est le design de la moulinette et de yunohost (pour la millième fois :p)
(15:21:07) Maniack C: Tu pourrais me le dire 10000 fois, n'ayant pas le nez dedans j'en comprend pas la profondeur
(15:21:16) Bram: oui je vois bien ça :p
(15:21:16) Maniack C: J'imagine
The `psutil.BOOT_TIME` attribute appears to be deprecated, and returns an `AttributeError` when called.
Even though the psutil documentation states that old attributes should be callable, one should use `psutil.boot_time()` function instead.
In some version of psutil (e.g. 2.1.1), both appear callable. In old versions (e.g. 1.2.1), `psutil.BOOT_TIME` is but `psutil.boot_time()` is not. In the newest version (4.3.0), only the latter can be called.
This bug would introduce an Internal Server Error (Error 500) when accessing the Monitor tool in the YunoHost admin panel.
Since monitoring statistics was not finished - and by the way not usable,
it inverts the behavior of monitor_enable to disable it by default.
See #395 for more details.
Fixed a number of minor English spelling and grammar errors in the messages (for example the word "list" implies plural, so no need to double pluralize by saying "apps list").
