mirror of
https://github.com/ansible-collections/community.general.git
synced 2026-05-13 05:02:17 +00:00
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
*
|
||
|---|---|---|
| .. | ||
| cloud | ||
| files | ||
| monitoring | ||
| net_tools | ||
| network | ||
| packaging | ||
| remote_management | ||
| source_control | ||
| system | ||
| web_infrastructure | ||
| __init__.py | ||
| conftest.py | ||
| utils.py | ||