# Using ansible modules as normal python modules

**URL:** <https://forum.ansible.com/t/using-ansible-modules-as-normal-python-modules/12644>\
**Category:** Ansible Project\
**Created:** [April 8, 2013, 12:50am UTC](https://forum.ansible.com/t/using-ansible-modules-as-normal-python-modules/12644 "2013-04-08T00:50:29Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steven\_Kryskalla](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@Steven\_Kryskalla](https://forum.ansible.com/u/Steven_Kryskalla)\
**Post date:** [April 8, 2013, 12:50am UTC](https://forum.ansible.com/t/using-ansible-modules-as-normal-python-modules/12644/1 "2013-04-08T00:50:29Z")

</div>

Hello,

I did a small experiment with turning the ansible "library" modules  
into python modules that can be imported and used from normal python  
code and wanted to see what other people think. Here is a demo of what  
it does:

[https://github.com/lost-theory/ansible/blob/module\_experiment/demo.py#L35](https://github.com/lost-theory/ansible/blob/module_experiment/demo.py#L35)

The changes are in this branch:

[https://github.com/lost-theory/ansible/commits/module\_experiment](https://github.com/lost-theory/ansible/commits/module_experiment)

My reason for doing this is that I think the code inside the modules  
is very useful, and it would be nice to import, extend, run, etc. from  
other python code. Right now they are sort of locked into running from  
the command line in a specialized way (INCLUDE\_ANSIBLE\_MODULE\_COMMON,  
hardcoding arguments into MODULE\_ARGS, etc.). There was a mailing list  
post from a few days ago where some folks were asking for something  
similar:

[https://groups.google.com/forum/?fromgroups=#!topic/ansible-project/7SByPqJxa7Q](https://groups.google.com/forum/?fromgroups=#!topic/ansible-project/7SByPqJxa7Q)

Some examples of things that would make this easier and would not  
disrupt the "language agnostic" goal too much:

1. move the "main()" call that is currently at the bottom of every  
module into an "if \_\_name\_\_ == '\_\_main\_\_'" block.  
2. use return values and exceptions instead of calling exit\_json or  
sys.exit directly  
3. import module\_common.py instead of writing its contents into each module  
4. allow for arguments to be passed into a module in a programmable  
way instead of the hardcoded MODULE\_ARGS "constant"

Would patches be accepted for those kinds of changes? Or is there a  
better way to do this kind of thing?

thanks,  
Steve

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 8, 2013, 3:44pm UTC](https://forum.ansible.com/t/using-ansible-modules-as-normal-python-modules/12644/2 "2013-04-08T15:44:53Z")

</div>

I am generally fine with modules being adapted to call exceptions and then have catchers that call exit\_json and so on, but it doesn’t bring me all that much benefit. In fact, it makes the code more complicated. Where as, right now, module.exit\_json is a very nice abstraction.

Importing module\_common also doesn’t make sense, as we’ve then transferred an extra file with an extra operation, where the entire goal was to keep the number of operations super-low.

Embedding arguments versus calling them on the command line was also a design decision that allows for complex argument transfer.

Ultimately I don’t see the benefit right now.

If some other code wants to use Ansible, it can go through the Ansible Runner API and get to all of the benefits.

---

<div class="post-metadata">

**Author:** ![Steven\_Kryskalla](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@Steven\_Kryskalla](https://forum.ansible.com/u/Steven_Kryskalla)\
**Post date:** [April 9, 2013, 3:11pm UTC](https://forum.ansible.com/t/using-ansible-modules-as-normal-python-modules/12644/3 "2013-04-09T15:11:06Z")

</div>

> I am generally fine with modules being adapted to call exceptions and then have catchers that call exit\_json and so on, but it doesn’t bring me all that much benefit. In fact, it makes the code more complicated. Where as, right now, module.exit\_json is a very nice abstraction.

I see.

> Importing module\_common also doesn’t make sense, as we’ve then transferred an extra file with an extra operation, where the entire goal was to keep the number of operations super-low.

If you create 10 users, that requires 10 file transfers of the user module (including 10x duplicate common code), right? Seems like factoring out module\_common and passing in arguments would get that down to ~2 file transfers with each file being smaller.

> Embedding arguments versus calling them on the command line was also a design decision that allows for complex argument transfer.

I see, but I don’t think it’s the only way. You could pass in complex args as a JSON string on the command line, or pipe the JSON into the script, or write the complex args to a file, or store the JSON string in an environment variable, etc.

> Ultimately I don’t see the benefit right now.
> 
> If some other code wants to use Ansible, it can go through the Ansible Runner API and get to all of the benefits.

Thanks I will take a look at that.

-Steve