Re: il faudrait le réécrire <s>en Rust</s> !

Mais en vrai, du Python avec de forts degrés d'indentations et sans découpage du code, c'est insupportable aussi. En fait n'importe quel langage.

Je préfère déjà :-D Ce n'est plus Y est râté et P est mieux alors qu'ils font la même.

Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).

Qu'entends-tu par « syntaxe ouvrante/fermante » ? Les formatages à la C par oppositions aux formatages par indentation ?

Sauf que, pour des états, des structures de données, la complexité peut être normale, alors que dans du code source, la normalité est de faire des fonctions, de la factorisation, pour garder des ensembles cohérent de code assez petits, et sans trop de niveaux d'imbrication.

Ansible est allé dans ce sens avec les roles et différentes include...
Mais intrinsèquement, les structures de données sont complexes et les host_vars/group_vars permettent un certain découpage (et pourtant je continue à en voir qui foutent tout dans un fichier d'inventaire ini qui contient déjà une ou deux centaines de machines)

[...] Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
[...] Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».

C'est souvent que le problème est mal posé ou son approche l'est. (Parfois j'ai l'impression que les gens pratiquent le « pourquoi faire simple quand on peut faire compliqué ? » et c'est encore plus vrai quand on se met martèle en tête que Ansible est un langage de programmation ...sauf que là c'est le début du masochisme)
Mais il y a des cas effectivement pas simples qui indique qu'on a atteint les limites d'Ansible de base : il faut soit créer ses propres modules ou y aller directement dans le langage qu'on maîtrise, sinon on fait des playbooks difficiles à maintenir et qui en plus vont rapidement vous péter au visage.

Dans ton exemple, il n'y a pas de Jinja2. Et l'alternative que tu préconises, indique que tu as plutôt besoin de Fabric ou Nuka ou similaire.

Je suis bien d'accord avec ce qui suit :

Mais bref, je trouve que c'est une dérive qu'on retrouve un peu trop dans Ansible, un peu sur le principe de quand on a un marteau, tous les problèmes ressemblent à des clous, si on a déjà une infra Ansible en place, on a envie de tout faire en Ansible.

C'est d'autant plus dommage que l'utilisation d'Ansible ne t'enferme pas, et que l'esprit unixien veut qu'on utilise l'outil qui va bien dans l pléthore qu'on a à disposition. C'est toujours une erreur de faire une fixette sur un outil spécifique.

Ansible doit-il se contenter d'être un outil de description d'état désiré, ou doit-il évoluer vers un outil de programmation distante comme on peut le voir de plus en plus ?

Il y a un besoin qu'il rempli bien et il n'y a pas de raison de changer cela. Pourquoi vouloir que ça fasse le boulot d'autres outils ? On doit arrêter avec les fixettes windowsienne ; la seule évolution que j'attends perso de ces diverses solutions est qu'elles puissent (mieux) communiquer entre elles de sorte à pouvoir être complémentaires.

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