Proxmoxer is a great library that allows you to access the proxmox rest API, but that requires to make a remote access request for each task, which among other things requires authentication management
Given the fact that ansible tasks are already running directly on the target machine, what’s the reason for these modules to not just directly manage the proxmox instance locally either by modifying the configuration files directly or by calling the proxmox cli?
This is out of curiosity
Hi there 
,
Once upon a time someone decided to make modules for proxmox and they decided to use proxmoxer in order to abstract the API and not implement that themselves.
I wasn’t involved in the development or the decision to do so.
From the practical side of things, it’s mainly about flexibility, running tasks in proxmoxer can be done on the Proxmox host itself, however, it doesn’t need to be.
If you’re running tasks on a PVE server on which you don’t have shell access for example, with proxmoxer you still can run automation against your own VMs (or, in the situation where you can also make VMs, still create those).
And not all modules are based on proxmoxer, I wrote the initial version of the community.proxmox.proxmox inventory and it triggered the same discussion (https://github.com/ansible-collections/community.general/pull/545 and add inventory plugin for Proxmox VE by xoxys · Pull Request #736 · ansible-collections/community.general · GitHub).
Back then I was a bit skeptical about using proxmoxer myself (‘because it was just an abstraction of an abstraction’, silly me) and I wanted to be able to only inventory VMs on systems on which getting proxmoxer was a challenge on it’s own. And it seems that the author of the other PR agreed, as that one was closed in favor of the one I wrote (but still many thanks to the foreman guys for making the framework I ripped from them 
)
So, TL;DR: reasons, but it can be a bit more flexible when using them, especially when you do not have shell access to the PVE node(s).
I didn’t work on the module, but I can hazard a guess.
The cli tools are pretty powerful, and you can easily brick your instances, and probably the server as well if you get carried away or misunderstand an option. The API on the other hand takes care of a lot of stuff like permissions and sequencing of requests, in such a way that its somewhat more difficult to break things. The API is indeed how the developers want you to interact with the service, and has had a lot of testing with various client libraries.
The API however, isn’t perfect and has rough edges for historical reasons. The developers of proxmoxer have done a lot of work to cover the API features sufficiently for most purposes, and the community has tested that integration in the real world.
So basically I think it would take a lot of work and careful consideration, if you were to build a proxmox module based around the CLI, that is already available between the API and proxmoxer.
That said, I have a bunch of ansible shell utilities for doing ad-hoc stuff directly with cli commands because I couldn’t do it with proxmoxer or the module.