Update info on python support (#38855)

* Update the documentation to list Python 3 as official
* Add some reference targets for inventory variables so we can link to docs
* Add a platform FAQ section
  Populate it with

  * virtualenv info (previously on the python3 support page)
  * BSD (Link to the working with BSD page)
  * Solaris (Document how to work around the non-POSIX shell on some
    Solaris hosts)

  Fixes #21594

* Fix some refs in the release_and_maintenance document

* Fix unindent error in module template

Fix for the module/plugin template unintentionally unindented inside of
a raw block, leading to errors like:

ERROR: docs/docsite/rst/modules/redshift_facts_module.rst:289:0: Explicit markup ends without a blank line; unexpected unindent.

* Make wording for Solaris troubleshooting better.
This commit is contained in:
Toshio Kuratomi 2018-04-18 13:04:47 -07:00 committed by GitHub
commit a08459a814
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
6 changed files with 166 additions and 94 deletions

View file

@ -389,21 +389,28 @@ ansible_become_flags
Remote host environment parameters:
ansible_shell_type
The shell type of the target system. You should not use this setting unless you have set the ``ansible_shell_executable`` to a non-Bourne (sh) compatible shell.
By default commands are formatted using ``sh``-style syntax.
Setting this to ``csh`` or ``fish`` will cause commands executed on target systems to follow those shell's syntax instead.
The shell type of the target system. You should not use this setting unless you have set the
:ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are
formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands
executed on target systems to follow those shell's syntax instead.
.. _ansible_python_interpreter:
ansible_python_interpreter
The target host python path. This is useful for systems with more
than one Python or not located at :command:`/usr/bin/python` such as \*BSD, or where :command:`/usr/bin/python`
is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's
path to be set right and also assumes the :program:`python` executable is named python, where the executable might
be named something like :program:`python2.6`.
ansible_*_interpreter
Works for anything such as ruby or perl and works just like ``ansible_python_interpreter``.
Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter`.
This replaces shebang of modules which will run on that host.
.. versionadded:: 2.1
.. _ansible_shell_executable:
ansible_shell_executable
This sets the shell the ansible controller will use on the target machine,
overrides ``executable`` in :file:`ansible.cfg` which defaults to