# Windows module\_utils, module API **URL:** \ **Category:** Ansible Developer\ **Tags:** windows\ **Created:** [October 14, 2015, 9:58pm UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507 "2015-10-14T21:58:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\ **Post date:** [October 14, 2015, 9:58pm UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507/1 "2015-10-14T21:58:08Z")
Soliciting opinions about building a real Powershell Ansible module API, rather than continuing to bolt on ad-hoc stuff to module\_utils/powershell.ps1… Well-intentioned PRs like [https://github.com/ansible/ansible/pull/12600/](https://github.com/ansible/ansible/pull/12600/) add useful functionality, but we’re missing a holistic module API like Python has. There’s also significant overlap in what PS already provides (ValidateSet, type coercion, etc), too, but the built-in PS stuff doesn’t exactly give the friendliest feedback. Everything we add to powershell.ps1 that actually gets used becomes a de-facto API, which means it’s hard to go back in time and make something consistent. We’re treading ground that has already been well-covered by the Python stuff. My preference would be to start from scratch, using the Python Ansible module API as a starting point, and attempt to get feature parity and an API that’s shaped pretty much like its Python counterpart. The use of PSObject for args kinda hamstrings us in that regard- I’ve already prototyped replacing ConvertFrom-Json with the built-in JavascriptSerializer (which can give us a dictionary instead). Thoughts? I’m sure we’re too late for 2.0, but if there’s appetite for this, I’m sure we could get it in for 2.1… -Matt ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [October 15, 2015, 11:51am UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507/2 "2015-10-15T11:51:39Z")
Another good idea (for after 2.0). I’d ask that whatever API we wind up with is versioned from the get-go so we can plan changes and give extras module owners time to switch to new versions of the API in the future. Jon ---
**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\ **Post date:** [October 16, 2015, 8:26am UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507/3 "2015-10-16T08:26:20Z")
I completely agree. That said, I don’t know the details of the python module, maybe we should start out by trying to come up with a requirements list? I would not mind building this into a PS module which we place on the target node (if it doesn’t already exist), so that we wouldn’t have to send the same code blocks to target nodes each time we send a play to a node. ---
**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\ **Post date:** [November 18, 2015, 8:27am UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507/4 "2015-11-18T08:27:55Z")
Any other thoughts on this? ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [November 20, 2015, 10:32pm UTC](https://forum.ansible.com/t/windows-module-utils-module-api/19507/5 "2015-11-20T22:32:24Z")
normally we try to keep changes from breaking backwards compatibility, if one of these is warranted we should make it a different function. Most of the times we try to add an extra optional parameter that defaults to the previous behavior. I might be missing something as I don't see the change that adds aliases as breaking compatibility.