custom modules & how to include custom files

[Raphael Randschau]

Hey there,

while working on [ansible-rails][1] I came across a problem I have not yet been able to solve by just reading and interpreting the ansible source code:

how can I share common dependencies between multiple, custom commands? E.g. given the following role directory structure:

/example

/example/library

/example/library/command_a

/example/library/command_b

/example/library/shared_utility.py

/example/library/__init__.py

shared_utility.py contains classes used in both command_a AND command_b. 

The way I understand ansible right now is that when command_a is used inside a playbook/ role it's source is expanded and copied to the server (sie ModuleReplacer inside the ansible source).

However, due to this processing, I can't just import shared_utility, because it's not copied to the remote server.

My question now is this: how do I import shared code into ansible commands? And equally important: how do I properly test these custom commands without much hackery (I'm talking about good old unit tests in this case!)

Please advice - is this left out on purpose or just very badly documented & hidden away?

Thanks,

Raphael

[1]:https://github.com/nicolai86/ansible-rails

[Michael DeHaan]

Hi Raphael,

If code lives in "module_utils" in Ansible, these pieces of code can be inserted into other modules.   This is currently not a configurable directory though where you can drop your own snippets.

I think basically this would warrant a pull request to add a configurable "module_utils" path that would be searched by the ModuleReplacer code in addition to the core.

"Please advice - is this left out on purpose or just very badly documented & hidden away?"

It doesn't exist now as a user configurable directory, so this is somewhat jumping to a wrong conclusion.

Ansible follows a "YAGNI" philosophy, most open source development is also based on itch-scratching.   AKA, nobody needed this.

As for testing, you really should write integration tests.

--Michael

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/93c6462b-75d2-4b16-8ae0-e02cc580f540%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Raphael Randschau]

Hi Michael,

thanks for the heads up. I'll be working on a proper PR for ansible then.

Regarding style, the magic syntax for inclusion feels deprecated, but it would be a cleaner way to include arbitrary files, without messing with pythons import syntax. What do you think?

Thanks for the heads up btw, ansible is the best thing that happened to automation in the past few years :)

[Michael DeHaan]

"Regarding style, the magic syntax for inclusion feels deprecated, but it would be a cleaner way to include arbitrary files, without messing with pythons import syntax."

Look at how all the modules in the tree do this now, which looks exactly like Python's import syntax.   This would still continue to be a "thing" even if multiple directories were supported.

(... now, your editor might not be able to find them for completion purposes, which was the point of the feature...)

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6407aeee-751b-434e-98e8-257af8ad0816%40googlegroups.com.

[Ananda Debnath]

Apologies if this topic has been hashed to death - but I wanted to follow up to see if there is a simple/clever way to solve this problem. I too am writing custom modules for Xen and there's a lot of boilerplate code common to many such modules that would be better off in a common shared python file rather than exist in each module file. It would definitely be nice if this could be done declaratively within each module file rather than hacking module_utils or some such "unsanctioned" mechanism.