Backportapalooza 06 30 (#78176)

* fixed hyperlinks to galaxy.ansible for issue #78104 (#78152)

(cherry picked from commit 4bd7e50612d4bff228506ea6f419abe2935bb04d)

* Fix documentation with misleading data type (#78157)

##### SUMMARY
The sample value given for the 'mode' parameter is shown without quotes, but the data type is string. If you actually try to use an unquoted numeric string for this value you're in for a nasty surprise! I added quotation marks to the sample value.
##### ISSUE TYPE
- Docs Pull Request

+label: docsite_pr

(cherry picked from commit 4c9385dab720ae5d33054d521cecda31464c8857)

* Update README.md (#78139)

Update Python version requirement to >= 3.8.

(cherry picked from commit 58b42abedeb844947393e1398307be9fb55db9ce)

* elaborate on import/include conditional example (#78138)

(cherry picked from commit 7ec84c511fc5df4a10b4f1b146d0195f690b6a5d)

* Update vault.rst (#78140)

(cherry picked from commit 84105e39f4d524c1002ce069c2fc818496ddff89)

Co-authored-by: Lewis Brogan <ilewisbrogan@gmail.com>
Co-authored-by: mlevens-hw <55262896+mlevens-hw@users.noreply.github.com>
Co-authored-by: Diana S. Cardona <89112552+Flecha21@users.noreply.github.com>
Co-authored-by: Sloane Hertel <19572925+s-hertel@users.noreply.github.com>
Co-authored-by: jlownie <jlownie@hotmail.com>

5 files changed, 27 insertions, 11 deletions

diff --git a/docs/docsite/rst/reference_appendices/glossary.rst b/docs/docsite/rst/reference_appendices/glossary.rst
index 1d274cede1..10fdd2dd4a 100644
--- a/docs/docsite/rst/reference_appendices/glossary.rst
+++ b/docs/docsite/rst/reference_appendices/glossary.rst
@@ -68,10 +68,10 @@ when a term comes up on the mailing list.
         The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco.
 
     community.general (collection)
-        A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do not have their own dedicated Collection. See `community.general <https://galaxy.ansible.com/community/general>`_` on Galaxy.
+        A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do not have their own dedicated Collection. See `community.general <https://galaxy.ansible.com/community/general>`_ on Galaxy.
 
     community.network (collection)
-        Similar to ``community.general``, focusing on network content. `community.network <https://galaxy.ansible.com/community/network>`_` on Galaxy.
+        Similar to ``community.general``, focusing on network content. `community.network <https://galaxy.ansible.com/community/network>`_ on Galaxy.
 
     Connection Plugin
         By default, Ansible talks to remote machines through pluggable
diff --git a/docs/docsite/rst/user_guide/playbooks_conditionals.rst b/docs/docsite/rst/user_guide/playbooks_conditionals.rst
index a0bd1506d6..3dadb616d6 100644
--- a/docs/docsite/rst/user_guide/playbooks_conditionals.rst
+++ b/docs/docsite/rst/user_guide/playbooks_conditionals.rst
@@ -280,14 +280,16 @@ You can use conditionals with re-usable tasks files, playbooks, or roles. Ansibl
 Conditionals with imports
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``:
+When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, if you want to define and then display a variable that was not previously defined, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``:
 
 .. code-block:: yaml
 
     # all tasks within an imported file inherit the condition from the import statement
     # main.yml
-    - import_tasks: other_tasks.yml # note "import"
-      when: x is not defined
+    - hosts: all
+      tasks:
+      - import_tasks: other_tasks.yml # note "import"
+        when: x is not defined
 
     # other_tasks.yml
     - name: Set a variable
@@ -314,7 +316,20 @@ Ansible expands this at execution time to the equivalent of:
       when: x is not defined
       # Ansible skips this task, because x is now defined
 
-Thus if ``x`` is initially undefined, the ``debug`` task will be skipped. If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself.
+If ``x`` is initially defined, both tasks are skipped as intended. But if ``x`` is initially undefined, the debug task will be skipped since the conditional is evaluated for every imported task. The conditional will evaluate to ``true`` for the ``set_fact`` task, which will define the variable and cause the ``debug`` conditional to evaluate to ``false``.
+
+If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself.
+
+.. code-block:: yaml
+
+    # using a conditional on include_* only applies to the include task itself
+    # main.yml
+    - hosts: all
+      tasks:
+      - include_tasks: other_tasks.yml # note "include"
+        when: x is not defined
+
+Now if ``x`` is initially undefined, the debug task will not be skipped because the conditional is evaluated at the time of the include and does not apply to the individual tasks.
 
 You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module <group_by_module>` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`.
 
diff --git a/docs/docsite/rst/user_guide/vault.rst b/docs/docsite/rst/user_guide/vault.rst
index b196f6125e..730b9fe177 100644
--- a/docs/docsite/rst/user_guide/vault.rst
+++ b/docs/docsite/rst/user_guide/vault.rst
@@ -476,7 +476,7 @@ You can set the following Emacs options to avoid cases of disclosure. There may
 Using encrypted variables and files
 ===================================
 
-When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or in the playbook itself.
+When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or by setting a default password source in a config option or an environment variable.
 
 Passing a single password
 -------------------------
@@ -575,7 +575,9 @@ If you use one vault ID more frequently than any other, you can set the config o
 Setting a default password source
 ---------------------------------
 
-If you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify that file. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins.
+If you don't want to provide the password file on the command line or if you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify a default file to use. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins.
+
+The file that you reference can be either a file containing the password (in plain text), or it can be a script (with executable permissions set) that returns the password.
 
 When are encrypted files made visible?
 ======================================
diff --git a/hacking/README.md b/hacking/README.md
index 46235579db..03c0868676 100644
--- a/hacking/README.md
+++ b/hacking/README.md
@@ -5,8 +5,7 @@ env-setup
 ---------
 
 The 'env-setup' script modifies your environment to allow you to run
-ansible from a git checkout using python 2.6+.  (You may not use
-python 3 at this time).
+ansible from a git checkout using python >= 3.8. 
 
 First, set up your environment to run from the checkout:
 
diff --git a/lib/ansible/modules/copy.py b/lib/ansible/modules/copy.py
index cb518d8227..ca6ae0df0e 100644
--- a/lib/ansible/modules/copy.py
+++ b/lib/ansible/modules/copy.py
@@ -268,7 +268,7 @@ mode:
     description: Permissions of the target, after execution.
     returned: success
     type: str
-    sample: 0644
+    sample: "0644"
 size:
     description: Size of the target, after execution.
     returned: success