La doc d'introduction met l'accent sur la facilité de prise en main ...ce qui peut être au détriment des bonnes pratiques :-S Probablement le prix à payer pour la bonne affiche (j'allais dire « pour être vendeur » avant de me rappeler que ce n'est pas vendu), en tout cas on ne cherche pas à décourager par certaines considérations.
Ainsi, je ne trouve pas très propre le YAML qui devrait ressembler plutôt à
Avoir une indentation correcte et cohérente est, comme avec Python, plus facile à lire et limite les erreurs.
Il faut, systématiquement mettre les chaînes entre « quotes » pour ne pas donner l'impression comme on l'a vu que tantôt il en faut parfois par magie ou sans raison.
Je ne fais exception que pour différencier les mots clés de l'outil : "latest", "directory", etc. Par contre, dans tous les cas, en ne quotant pas "yes" je différencie bien le booléen de la chaîne de caractères (et certains linters veulent même qu'on utilise carrément "true" et rien d'autre)
Utiliser "latest" montre bien que l'outil n'impose rien et qu'on peut l'utiliser pour mettre à jour aussi sans trop de prise de tête, mais cette option va à l'encontre des bonnes pratiques si on veut être idempotent...
Maintenant, venons au cas de Jinja2, où encore on a marché sur les bonnes pratiques au profit de la facilité... car l'utilisation de "content" dans le module copy est vraiment à réserver au dernier recours. Et dans cet exemple précisément, on était dans un cas où il aurait fallut faire appel au module template... Tout cela illustre mon propos (l'outil est permissif, ce qui permet de le prendre en main facilement mais avec le revers de pouvoir faire aussi des choses pas proprettes...) Le « FAST » dans le titre indique que les petites violations des bonnes pratiques sont assumées et ça me va : vite fait ne peut être toujours 100% bien fait...
Je reviens au point qui préoccupe. Comme les éditeurs font de la coloration syntaxique pour du YAML c'est donc du YAML pur qui est vu et mis en évidence. Pour répondre à ton/ta besoin/demande, il faudrait rajouter une déclinaison qui serait la prise en compte du DSL... Pour faire une analogie, quand tu ouvres un document XHTML dans un éditeur qui le voit comme du XML, ça va certes reconnaitre qu'il y a des balises et des attributs et pouvoir indiquer les imbrications etc. Mais contrairement à un éditeur HTML pur, ça ne reconnait pas la sémantique qui lui permettrait de distinguer les balises valides des balises farfelues, et reconnaître proprement JS et CSS dedans. C'est exactement ce qu'il manque avec la prise en compte de Jinja2 dans du YAML (et c'est valable aussi si on utilise quelque autre mécanisme : j'ai perso déjà eu à faire des modèles YAML avec des variables shell mais les éditeurs ne savaient pas mettre ces intrus en évidence.)
Je pense/espère que l'éditeur que tu utilises te permets de définir assez facilement ton fichier de coloration syntaxique. Auquel cas, il te faudra partir de celui du YAML et adapter jusqu'à obtenir ton bonheur. Perso, j'utilise essentiellement Vim mais n'ayant pas eu le besoin, je n'ai pas spécialement creusé la question. Je trouve cependant pearofducks/ansible-vim et chase/vim-ansible-yaml (ou erikzaadi/vim-ansible-yaml entre autres) qui mettent en évidence des éléments du DSL. Je n'ai pas testé car je reste plus avec le fonctionnement de base et quelques réglages. Il y a divers approches avec cet éditeur (on parle par exemple de rocannon/vim-assimilate/vim-polyglot par exemple.)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 2.
La doc d'introduction met l'accent sur la facilité de prise en main ...ce qui peut être au détriment des bonnes pratiques :-S Probablement le prix à payer pour la bonne affiche (j'allais dire « pour être vendeur » avant de me rappeler que ce n'est pas vendu), en tout cas on ne cherche pas à décourager par certaines considérations.
Ainsi, je ne trouve pas très propre le YAML qui devrait ressembler plutôt à
On va dire que je chipote, mais :
latest", "directory", etc. Par contre, dans tous les cas, en ne quotant pas "yes" je différencie bien le booléen de la chaîne de caractères (et certains linters veulent même qu'on utilise carrément "true" et rien d'autre)latest" montre bien que l'outil n'impose rien et qu'on peut l'utiliser pour mettre à jour aussi sans trop de prise de tête, mais cette option va à l'encontre des bonnes pratiques si on veut être idempotent...Maintenant, venons au cas de Jinja2, où encore on a marché sur les bonnes pratiques au profit de la facilité... car l'utilisation de "
content" dans le modulecopyest vraiment à réserver au dernier recours. Et dans cet exemple précisément, on était dans un cas où il aurait fallut faire appel au moduletemplate... Tout cela illustre mon propos (l'outil est permissif, ce qui permet de le prendre en main facilement mais avec le revers de pouvoir faire aussi des choses pas proprettes...) Le « FAST » dans le titre indique que les petites violations des bonnes pratiques sont assumées et ça me va : vite fait ne peut être toujours 100% bien fait...Je reviens au point qui préoccupe. Comme les éditeurs font de la coloration syntaxique pour du YAML c'est donc du YAML pur qui est vu et mis en évidence. Pour répondre à ton/ta besoin/demande, il faudrait rajouter une déclinaison qui serait la prise en compte du DSL... Pour faire une analogie, quand tu ouvres un document XHTML dans un éditeur qui le voit comme du XML, ça va certes reconnaitre qu'il y a des balises et des attributs et pouvoir indiquer les imbrications etc. Mais contrairement à un éditeur HTML pur, ça ne reconnait pas la sémantique qui lui permettrait de distinguer les balises valides des balises farfelues, et reconnaître proprement JS et CSS dedans. C'est exactement ce qu'il manque avec la prise en compte de Jinja2 dans du YAML (et c'est valable aussi si on utilise quelque autre mécanisme : j'ai perso déjà eu à faire des modèles YAML avec des variables shell mais les éditeurs ne savaient pas mettre ces intrus en évidence.)
Je pense/espère que l'éditeur que tu utilises te permets de définir assez facilement ton fichier de coloration syntaxique. Auquel cas, il te faudra partir de celui du YAML et adapter jusqu'à obtenir ton bonheur. Perso, j'utilise essentiellement Vim mais n'ayant pas eu le besoin, je n'ai pas spécialement creusé la question. Je trouve cependant pearofducks/ansible-vim et chase/vim-ansible-yaml (ou erikzaadi/vim-ansible-yaml entre autres) qui mettent en évidence des éléments du DSL. Je n'ai pas testé car je reste plus avec le fonctionnement de base et quelques réglages. Il y a divers approches avec cet éditeur (on parle par exemple de rocannon/vim-assimilate/vim-polyglot par exemple.)
"It is seldom that liberty of any kind is lost all at once." ― David Hume