C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script. C'est comme dire qu'une Ferrari F50 est un mauvais véhicule pour transporter ses meubles.
Sinon, il y avait déjà des outils comme fabric ou tu prends directement python, il n'y avait pas besoin de refaire la roue. Ou pour plus moderne, Bearstech a écrit Nuka.
Limiter ce que l'outil permet est une décision consciente, que les devs n'aiment pas, mais curieusement, les devs ne se jettent pas sur les alternatives cités plus haut qui n'ont pas de limitation sur le script. C'est un peu tout le concept de "revelead preference".
Ensuite, quand à yaml par rapport à un DSL qui plairement mieux à quelqu'un, je suis sur que ça changerait rien vu que si on arrive pas à se mettre d'accord sur les languages de script, un de plus ne va rien changer. Autant dire que c'est pas trés utile comme remarque.
Par contre, ce qu'on peut regarder si on veut avoir une remarque utile, c'est l'impact de prendre yaml par rapport à un DSL custom. Par exemple, utiliser yaml permet de fairel'analyse statique de façon assez trivial. Exemple, tu peux avoir un règle de d'abord installer les paquets, et de lancer le service à la fin. Si tu as un DSL maison comme puppet/salt ou un language complet (chef, par exemple), tu dois refaire un parser. En utilisant quelque chose comme yaml/toml/xml/json, un dev normal va pouvoir le faire, pour des scripts de post commits, etc.
Quand à "ansible a besoin de code", ouais, réinventer la roue n'est pas toujours une solution. Tu peux essayer d'aller convaincre l'upstream python de mettre le support de maven dans la lib standard ceci dit.
On pourrait aussi noter qu'en prenant une solution intégré avec aucun OS comme maven, on se retrouve à devoir payer ce coût de non intégration à chaque fois. Si les paquets java avaient repris le format rpm, ou simplement pip, la question ne se poserait pas.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Misc (site web personnel) . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 7.
C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script. C'est comme dire qu'une Ferrari F50 est un mauvais véhicule pour transporter ses meubles.
Sinon, il y avait déjà des outils comme fabric ou tu prends directement python, il n'y avait pas besoin de refaire la roue. Ou pour plus moderne, Bearstech a écrit Nuka.
Limiter ce que l'outil permet est une décision consciente, que les devs n'aiment pas, mais curieusement, les devs ne se jettent pas sur les alternatives cités plus haut qui n'ont pas de limitation sur le script. C'est un peu tout le concept de "revelead preference".
Ensuite, quand à yaml par rapport à un DSL qui plairement mieux à quelqu'un, je suis sur que ça changerait rien vu que si on arrive pas à se mettre d'accord sur les languages de script, un de plus ne va rien changer. Autant dire que c'est pas trés utile comme remarque.
Par contre, ce qu'on peut regarder si on veut avoir une remarque utile, c'est l'impact de prendre yaml par rapport à un DSL custom. Par exemple, utiliser yaml permet de fairel'analyse statique de façon assez trivial. Exemple, tu peux avoir un règle de d'abord installer les paquets, et de lancer le service à la fin. Si tu as un DSL maison comme puppet/salt ou un language complet (chef, par exemple), tu dois refaire un parser. En utilisant quelque chose comme yaml/toml/xml/json, un dev normal va pouvoir le faire, pour des scripts de post commits, etc.
Quand à "ansible a besoin de code", ouais, réinventer la roue n'est pas toujours une solution. Tu peux essayer d'aller convaincre l'upstream python de mettre le support de maven dans la lib standard ceci dit.
On pourrait aussi noter qu'en prenant une solution intégré avec aucun OS comme maven, on se retrouve à devoir payer ce coût de non intégration à chaque fois. Si les paquets java avaient repris le format rpm, ou simplement pip, la question ne se poserait pas.