mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
52449cc01a
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 | ||
sanity | ||
__init__.py | ||
ansible_util.py | ||
changes.py | ||
classification.py | ||
config.py | ||
core_ci.py | ||
cover.py | ||
delegation.py | ||
diff.py | ||
docker_util.py | ||
executor.py | ||
git.py | ||
http.py | ||
import_analysis.py | ||
manage_ci.py | ||
metadata.py | ||
powershell_import_analysis.py | ||
pytar.py | ||
target.py | ||
test.py | ||
thread.py | ||
util.py |