yb, le parser YAML en bash revient dans une version plus mature "bug-less". J'ai pu éprouver la librairie en remplaçant le bien connu yq par yb dans loco.sh.
De mon point de vue, yb offre une API beaucoup plus simple et intuitive que d'autres solutions de parsing YAML s'appuyant régulièrement sur des DSLs compliqués et parfois fragiles.
Côté bash, aucune autre librairie ne propose une couverture aussi complète d'édition YAML. yb permet la lecture, l'ajout, le retrait et la modification des sélecteurs et des valeurs, quelle que soit la profondeur de l'arborescence du fichier YAML. Et ce, sans utiliser ni awk, ni sed.
Pour l'instant je pense figer les features et avancer vers une v1.0 quand j'aurai plus de retours de la communauté.
Merci pour votre soutien :
https://github.com/t0pd4wn/yb
https://gitlab.com/t0pd4wn/yb
# Intéressant
Posté par Marotte ⛧ . Évalué à 3.
Tu fais référence à
jq? Je le trouve assez imbitable. perso.[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
yq
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par Marotte ⛧ . Évalué à 4.
OK merci. Donc question syntaxe c’est kifkif, la différence de
yqpar rapport àjqc’est le support de plus de format que seulement le YAML, mais moins de fonctionnalités (qui sont prévues si je me fie au README), et le langage dans lequel il est implémenté (Go vs. C pourjq).Tout ça pour dire que
ybm’intéresse fortement. Le seul inconvénient (pas négligeable d’après-moi), en rapport avec la discussion que nous avions sur Bash, c’est queybn’est forcément packagé forcément par les ditributions (il l’est pas sur Bookworm en tous cas). Est-ce que le fait qu’il soit natif (ie: en Bash) ne résout pas forcément tout les problèmes de « de simplification de l’environnementdontt til a besoin ».si on le copie dans son propre projet il faut suivre ses mises à jour. Ce qui est plutôt simple avec les sous modules git, ça déporte toujours la gestion de l’environnement pour son propre au projet lui-même au lieu de se reposer sur les distributions qui font tourner son projet, et qui gèrent toutes les mises à jour de jq.
pour l’installation, si Ansible (ou autre outil de ce type) peut aussi bien gérer l’installation d’un RPM/DEB que le déploiement d’un script ça nécessite quand même toujours de considérer le premier point.
<block type=spam category=biography interest=0.0032 >
Clairement, je chipote grave et c’est peut-être moi qui ne travaille pas de la bonne manière (surtout que je dois parfois me résoudre à travailler de manières que je sais plus nulles que les miennes). Je ne suis pas chef et j’ai un certain nombre de collègue, ingénieurs comme moi (et pas des anciens à un ou deux ans de la retraite…), ingénieurs d’exploitation, des opérationnels donc, qui assument sans réserve, de ne pas savoir utiliser git/Github et de tenir à une gestion des opérations basée sur des documents Word, comme ils font depuis des dizaines d’année. Ils n’ont pas le temps de se former à git/Github vu leur charge de travail quotidien. Ajoutant qu’il faut également du temps pour étudier que la pertinence de passer de leur mode de gestion actuel à git/Github est vraiment réelle. Quand tu as un management qui a pas la volonté et la capacité à imposer ce genre de changement. Et bien… tu fais du devops/gitops surtout sur le papier et ça reste à l’état de projet. Mois qui suis fataliste et assez versatile (je ne fais rien vraiment bien mais rien non plus vraiment mal ) je me fais une raison. Mais quand je vois un collègue qui lui s’impose à lui même, et pousse pour, une gestion devops/gitops à la pointe de la discipline (ce qu’on ne peut pas lui reprocher, à moins d’un manque flagrant de pragmatisme sur un point, ce qui est très rare), je suis sûr que ça participe pas à sa satisfaction dans son travail.
</block>
[^] # Re: Intéressant
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 24 février 2024 à 23:35.
J’ai oublié la conclusion importante :
Malgré le seul défaut hautement capillotracté que j’ai cité, je vais très probablement user de
ybsi mes tests sont concluant que et que j’ai un truc non trivial à faire sur du JSON plutôt, que me faire chier avecjqet sa syntaxemerdiquetrop exigeante. C’est très probablement un excellent outil que j’espère packagé d’office un jour dans toutes les bonnes distrib’ !# Question hors-sujet sur l’organisation
Posté par Marotte ⛧ . Évalué à 5.
C’est sûrement assez courant mais je ne crois pas avoir déjà vu le cas.
Je vois les avantages à avoir le projet hébergé à la fois sur Github et sur Gitlab (merci Git !) mais j’ai du mal à voir comment tu organises ça en pratique ? Par exemple pour gérer les issues qui sont manifestement possible des deux côtés (et sans même une recommendation dans le README), etc…
Il y a un service de synchro proposé par l’une ou l’autre des plateforme ? Non mais tu as déjà un peu réfléchi au problème ? Je me pose trop de questions ?
# Des réponses
Posté par t0pd4wn . Évalué à 1.
Bonjour bonjour,
je fais effectivement référence à une solution qui se termine en
q:)Merci @Marotte pour ce témoignage opérationel des organisations logicielles :D
Étant à la 0.9 je pense qu'il se passera encore du temps avant que
ybsoit intégré nativement à Debian :') L'idée est que l'API et la v1.O soient suffisemment robustes pour être packagés directement dans le projet (30Ko pour la version minifiée). À priori les montées de version ne devraient apporter que de nouvelles fonctionnalités au regard du standard YAML et pas de changements dans l'API ou le moteur.Pour la partie Gitlab / Github, il existe dans Gitlab un mécanisme natif de mirroring par token très pratique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.