Funny thing: judging by the styling, that text might be from the documentation for Ansible, the declarative configuration manager. Well, you can’t run Ansible itself in Windows, you need a *nix vm, even if WSL — though you can control Windows machines via Ansible. Afaik the same is true for the popular alternatives Salt, Puppet and Chef.
I generally have very mixed results with searches for longer text, these days. At some point, search engines overshot with synonyms and such fuzzy matching.
Hm? Most of the time the config is like ‘these packages should be installed, and these files should be in these directories’. Even stuff that requires running shell commands can and should be written in an idempotent way, basically just checking if the changes are already done.
Though Ansible kept introducing features like loops and conditionals, but the latter are required for aforementioned checks, and loops are useful for sanity. I’m more irked that they basically reinvented Lisp again, but with an inconvenient syntax.
I was talking about playbooks mostly, not individual tasks.
E.g. if you have a playbook where in one location you make sure a package is installed and in another to add a line to its config files, you need to ensure installation is performed first.
Another generic example is conflicting definitions, e.g. you define a package as present and somewhere else you define that one of its dependencies should be absent. Depending on the order, you either get an error or it works fine (but ignores the package absent directive). Or is my understanding wrong here?
You’re correct, of course — the tasks have to run in a certain order. I can vaguely imagine a config manager that calculates dependencies between the tasks before executing them, kinda like apt does. However, considering the complex relations between various kinds of things like packages, files, keys in a database like Gnome’s settings, running programs, etc., I doubt that it would be feasible to do that. One would have to describe the entirety of these relations for a program, in a format understandable by the manager — or at the very least write a bunch of checks for the prerequisites. Idk if anything like Nix attempts this kind of thing.
Funny thing: judging by the styling, that text might be from the documentation for Ansible, the declarative configuration manager. Well, you can’t run Ansible itself in Windows, you need a *nix vm, even if WSL — though you can control Windows machines via Ansible. Afaik the same is true for the popular alternatives Salt, Puppet and Chef.
(Though I couldn’t find the screenshotted page.)
Can’t find it via web search 🤔 interesting it wasn’t published in that same form, feel it’s rare to come up empty on something like this
I generally have very mixed results with searches for longer text, these days. At some point, search engines overshot with synonyms and such fuzzy matching.
Ansible declarative? That takes a lot of effort I think.
Hm? Most of the time the config is like ‘these packages should be installed, and these files should be in these directories’. Even stuff that requires running shell commands can and should be written in an idempotent way, basically just checking if the changes are already done.
Though Ansible kept introducing features like loops and conditionals, but the latter are required for aforementioned checks, and loops are useful for sanity. I’m more irked that they basically reinvented Lisp again, but with an inconvenient syntax.
I was talking about playbooks mostly, not individual tasks.
E.g. if you have a playbook where in one location you make sure a package is installed and in another to add a line to its config files, you need to ensure installation is performed first.
Another generic example is conflicting definitions, e.g. you define a package as present and somewhere else you define that one of its dependencies should be absent. Depending on the order, you either get an error or it works fine (but ignores the package absent directive). Or is my understanding wrong here?
You’re correct, of course — the tasks have to run in a certain order. I can vaguely imagine a config manager that calculates dependencies between the tasks before executing them, kinda like apt does. However, considering the complex relations between various kinds of things like packages, files, keys in a database like Gnome’s settings, running programs, etc., I doubt that it would be feasible to do that. One would have to describe the entirety of these relations for a program, in a format understandable by the manager — or at the very least write a bunch of checks for the prerequisites. Idk if anything like Nix attempts this kind of thing.