* Fix plugin names for collection plugins.
Add an integration test to verify plugin __name__ is correct for collection plugins.
* Fix collection loader PEP 302 compliance.
The `find_module` function now returns `None` if the module cannot be found. Previously it would return `self` for modules which did not exist.
Returning a loader from `find_module` which cannot find the module will result in import errors on Python 2.x when using implicit relative imports.
* add changelog
* sanity/units/merge fixes
In some remote environments, the `crontab` executable is
overloaded with a custom executable, which typically does
some pre/post processing before forwarding to crontab.
Instead of using the hardcoded `/usr/bin/crontab`, this uses
the `get_bin_path` utility to locate the default crontab executable.
* Add integration tests for ansible-doc.
* Enable tests that now pass
* Cleanup processing of plugin docs
* Mostly separate the steps of processing plugin docs
1) Acquire source data
2) Transform and calculate additonal data
3) Format data for output
4) Output data
format_plugin_doc() is still mixing transformation and formatting but
that should be fixed in a devel-only change
* Raise exceptions in _get_plugin_doc() on errors.
* Remove check to exclude on blacklisted extensions. We already request
only .py files
* If there is no DOCUMENTATION entry in the plugin, raise an exception
from _get_plugin_doc(). Everywhere we use _get_plugin_doc(), this is
treated as an error
* If there is no ANSIBLE_METADATA raise an exception as well as
displaying of docs assumes that this has been set.
* If there is neither DOCUMENTATION nor ANSIBLE_METADATA, warn about the
lack of METADATA and error on the lack of DOCUMENTATION. Lack of
DOCUMENTATION is more important so it is what the user should see.
* Add a few special cases for backwards compat. These should probably
be made errors in 2.10:
* no docs but has metadata shows no documentation rather than an error
* empty plugin file shows no doumentation rather than an error
* Simplify backwards compatibility logic.
VMware VSphere SDK needs an up to date version of `pip` for the
installation step. With the current image, we face the following error:
```
(...)
02:27 Collecting git+https://github.com/vmware/vsphere-automation-sdk-python.git (from -r /root/ansible/test/lib/ansible_test/_data/requirements/integration.cloud.vcenter.txt (line 2))
02:27 Cloning https://github.com/vmware/vsphere-automation-sdk-python.git to /tmp/pip-req-build-pm27t16b
02:33 Requirement already satisfied: pyvmomi in /usr/local/lib/python3.6/dist-packages (from -r /root/ansible/test/lib/ansible_test/_data/requirements/integration.cloud.vcenter.txt (line 1)) (6.7.1.2018.12)
02:33 Requirement already satisfied: lxml>=4.3.0 in /usr/local/lib/python3.6/dist-packages (from vSphere-Automation-SDK==1.4.0->-r /root/ansible/test/lib/ansible_test/_data/requirements/integration.cloud.vcenter.txt (line 2)) (4.4.0)
02:33 Processing ./\\localhost/tmp/pip-req-build-pm27t16b/lib/vapi-runtime/vapi_runtime-2.12.0-py2.py3-none-any.whl
02:33 Could not install packages due to an EnvironmentError: [Errno 2] No such file or directory: '/root/ansible/\\\\localhost/tmp/pip-req-build-pm27t16b/lib/vapi-runtime/vapi_runtime-2.12.0-py2.py3-none-any.whl'
```
Bump default-test-container to 1.9.3 to get an up to date release of
`pip` (was 19.0.2, is now 19.2.3).
* Clarifying pip module requirements in reference to #47361
* Further clarifying message with link to ansible_python_interpreter
* Clarifies pip behavior
* incorporates review feedback
Matt Clay