• [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par (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.

    Un linter qui va avec ça.

    Je l'ai mentionné dans un autre commentaire :

    pip install yamllint
    # c'est générique et servira pour tout YAML qu'on trouve ci et là
    # par défaut c'est assez strict et je ne pense pas que l'exemple passe
    pip install ansible-lint
    # c'est très laxiste sur le YAML, comparativement à l'autre
    # ça vérifie les bonnes pratiques émises au fil du temps

    Je mets ça en place aussi dans mes CI/CD.

    Bref quand on superpose des syntaxes existantes, on obtiens pas le meilleur de chaque monde, mais le pire. On crée un nouveau format qui n'est que partiellement pris en charge un peu partout et cette prise en charge partielle et par effet goodenought ralenti fortement l'émergence d'outils agréables à utiliser.

    Je dis justement que ça ne ralenti par certaines personnes (comme moi qui ne recherche pas de syntaxe particulière) mais sinon c'est bien une nouvelle syntaxe...
    On peut faire le même parallèle pour DocBook et d'autres comparé à XML au sens générique. J'ai des collègues qui ont du mal parce-que n'ayant pas de syntaxe spécifique alors que moi non.
    On peut faire le même parallèle pour tous les DSL (aussi bien celui de Puppet que celui de Structurizr avec lequel je travaille actuellement.)

    Et non la solution n'est pas de tripatouiller les fichiers de syntaxes de ton éditeur, tu va avoir un truc qui marchote plus ou moins. La solution c'est d'utiliser le LSP proposé par le projet, mais voila son développement n'a commencé que l'an dernier pour un projet qui a 10 ans.

    Ça revient au même pour moi. Si tu utilises lsp, bah il faut créer les fichiers de syntaxe lsp (ou attendre que quelqu'un fasse le tripatouillage pour toi.)
    Ensuite j'ai donné des exemples pour Vim qui ont cinq à sept ans d'existence.

    En tout cas si je regarde les playbook les mieux notés d'ansible galaxy, ils appliquent tous la règles "on ne quotes que les chaines pour les quel c'est nécessaire". Bon est pour aller plus loin encore c'est aussi la règle qui est utilisée dans le dépôt de playbooks servant à illustrer les bonnes pratiques pointées par la doc d'ansible comme quoi.

    La « bonne habitude » est de « juste mettre les quotes pour les chaînes de caractères. » Beaucoup d'erreurs auxquels j'ai répondu sur le forum étaient juste liées à ça : on a pris le raccourci autorisé par YAML et on n'a pas compris ce qui a merdé. Que de temps perdu en n'ayant pas fait les choses correctement dès le départ ?

    Quel est le problème avec l'indentation ?

    Seconde et troisième lignes (« become: yes et tasks: ») ; ça m'a piqué les yeux ...et ça rend l'interprétation ambigüe (est-ce bien au même niveau que hosts: webservers ou au niveau de l'élément de liste - hosts: webservers ? certains diront qu'il y a une espace, mais comme pour Python il est mieux d'avoir un nombre paire d'espaces et surtout le même partout hors on en est à 2 sous tasks...)

    "It is seldom that liberty of any kind is lost all at once." ― David Hume