I switched from Ansible to Pyinfra for my homelab, and continue to use Ansible at work.
The biggest difference is that Pyinfra is simply Python code. It's incredibly easy to control the system in whatever manner you need to. You can probably do the same thing in Ansible, but it's never quite as obvious how to do it. This also means it's much more clear where and why things work the way they do in Pyinfra, where in Ansible I end up digging through numerous role files to try to find where some variable gets injected.
Just having "home/docker.py" instead of "collections/ansible_collections/home/dev/roles/docker/tasks/main.yml" is reason enough. Which one of the 300 main.yml files do I load when doing a quick open in any modern text editor?
If Jinja templating for data manipulation gets too complex or inconvenient, you can create your own module in ansible and use python code for data manipulation. But at this point you are better served with plain python which I think is where pyinfra should shine. I want to take a look though at how hard it is to implement your own module for it.
I used ansible for building simple logging appliance (something like Elasticsearch + Dashboards + other tooling) and I found it very difficult to reason with specifically python code snippets within YAML.
Switched to Pyinfra and the difference is day and night. You write python code you can organise your stuff into functions, classes and whatever you like and then instantiate them as you like. Highly reusable configuration.
You have full pwoer such as you can call boto to fetch the list of servers to target, filter base on tags and what not. Only sky is the limit because it is NOT a DSL (or YAML) rather full blow real python.
Adding to sibling comments: I used to use Ansible professionally and PyInfra for homelab. Ansible is ridiculously slow.
The only issue was I had to implement some facts and operations myself that probably were available in some Ansible package but to be honest it was trivial.
At a previous job we used it to test our ansible playbooks via molecule, which were part of a CI/CD pipeline to create AWS AMIs.
It worked well and was nicer to deal with than test kitchen for testing UNIXy things (is service running and/or enabled, does file have right permissions, does file include $TEXT, etc). It was very useful for us during big linux upgrades, such as when ubuntu went from upstart to systemd. It can also be good at capturing edge cases with brittle outcomes (especially as ansible went through enormous changes after the red hat acquisition).
I used it between 20016-2023 and since we were not a python shop, I never used any other package managers. It was never an issue with CI/CD pipeline, but iterating locally was always a fight to getting molecule to pick up the right pyenv. It got better towards the end, though.
Honestly the bigger issue was testing x86 docker images on an arm mac, as molecule didn't cleanly support cross platform images and we did pull in x86 binaries for our playbooks (by the end of my time at said company, I was also directly managed by product managers who didn't care about tech debt and I couldn't deal with the otherwise desirable idea to move our compute to ARM - a rant for another day). This may also be fixed now.
I switched from Ansible to Pyinfra for my homelab, and continue to use Ansible at work.
The biggest difference is that Pyinfra is simply Python code. It's incredibly easy to control the system in whatever manner you need to. You can probably do the same thing in Ansible, but it's never quite as obvious how to do it. This also means it's much more clear where and why things work the way they do in Pyinfra, where in Ansible I end up digging through numerous role files to try to find where some variable gets injected.
Just having "home/docker.py" instead of "collections/ansible_collections/home/dev/roles/docker/tasks/main.yml" is reason enough. Which one of the 300 main.yml files do I load when doing a quick open in any modern text editor?
The worst part of Ansible is data manipulation, what would be an easy dictionary operation in Python is a huge mix of lookups in Ansible.
Incredibly frustrating that the data you want is right there but you can't easily grab it.
If Jinja templating for data manipulation gets too complex or inconvenient, you can create your own module in ansible and use python code for data manipulation. But at this point you are better served with plain python which I think is where pyinfra should shine. I want to take a look though at how hard it is to implement your own module for it.
If you're doing data manipulation with server state, you would probably want to create a Fact[0]. This is a straightforward Python class.
If you're doing data manipulation locally you would simply write Python code.
Operations[1] are Python functions which execute (yield) commands which will be run on hosts.
That's the gist of what it takes to write custom modules for Pyinfra.
[0] https://docs.pyinfra.com/en/3.x/api/facts.html [1] https://docs.pyinfra.com/en/3.x/api/operations.html
Pyinfra is what ansible should have been. It's straight python rather than a janky mix of yaml, templates, and bolted-on control flow primitives.
There is this: https://github.com/seantis/suitable
But the main guy who developed it at that company left, so no idea on its longevity.
Oh hey that's me! Yeah I don't think you would want to use this, it was never used outside some smaller automation utils afaik.
Yeah I guess; I'm generally not a fan of solving a problem by adding another layer of shit on top.
I used ansible for building simple logging appliance (something like Elasticsearch + Dashboards + other tooling) and I found it very difficult to reason with specifically python code snippets within YAML.
Switched to Pyinfra and the difference is day and night. You write python code you can organise your stuff into functions, classes and whatever you like and then instantiate them as you like. Highly reusable configuration.
You have full pwoer such as you can call boto to fetch the list of servers to target, filter base on tags and what not. Only sky is the limit because it is NOT a DSL (or YAML) rather full blow real python.
Adding to sibling comments: I used to use Ansible professionally and PyInfra for homelab. Ansible is ridiculously slow.
The only issue was I had to implement some facts and operations myself that probably were available in some Ansible package but to be honest it was trivial.
At a previous job we used it to test our ansible playbooks via molecule, which were part of a CI/CD pipeline to create AWS AMIs.
It worked well and was nicer to deal with than test kitchen for testing UNIXy things (is service running and/or enabled, does file have right permissions, does file include $TEXT, etc). It was very useful for us during big linux upgrades, such as when ubuntu went from upstart to systemd. It can also be good at capturing edge cases with brittle outcomes (especially as ansible went through enormous changes after the red hat acquisition).
Dislikes? I had to fight with pyenvs a bit..
was this before uv? i feel like my pyenv struggles basically ceased once I started using it
I used it between 20016-2023 and since we were not a python shop, I never used any other package managers. It was never an issue with CI/CD pipeline, but iterating locally was always a fight to getting molecule to pick up the right pyenv. It got better towards the end, though.
Honestly the bigger issue was testing x86 docker images on an arm mac, as molecule didn't cleanly support cross platform images and we did pull in x86 binaries for our playbooks (by the end of my time at said company, I was also directly managed by product managers who didn't care about tech debt and I couldn't deal with the otherwise desirable idea to move our compute to ARM - a rant for another day). This may also be fixed now.
Ansible includes modules to handle cloud resources as well, such as AWS Lambda.