Answers: <p>There are two options either you make sure you use the same Python version on each host or you make sure the right packages are installed on each platform.</p>
  
  <h2>Chose same Python interpreter</h2>
  
  <p>Provide the python binary to use. Since you have a Debian on each host, the location is always the same. If you know a Python version that is available on each host, go for this.</p>
  
  <p>Either in your inventory <code>hosts</code></p>
  
  <pre><code>[webserver]
  srv1.example.com
  srv2.example.com
  
  [webserver:vars]
  ansible_python_interpreter=/usr/bin/python3
  </code></pre>
  
  <p>Or in your Ansible configuration <code>ansible.cfg</code></p>
  
  <pre><code>ansible_python_interpreter=/usr/bin/python3
  </code></pre>
  
  <p>See also <a href="https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html#using-python-3-on-the-managed-machines-with-commands-and-playbooks" rel="nofollow noreferrer">https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html#using-python-3-on-the-managed-machines-with-commands-and-playbooks</a></p>
  
  <h2>Package per Python version</h2>
  
  <p>If you do not know whether either Python 3 or 2 is available on each host, ensure to get the right package for each Python version.</p>
  
  <pre><code>- apt:
      name: python-pip
    when: ansible_python.version.major==2
  
  - apt:
      name: python3-pip
    when: ansible_python.version.major==3
  </code></pre>
  
  <p>You may face the same issue when installing Python packages. So you can put your Pythone version specific tasks in a v2 and in a v3 file and conditionally include one for version 2 and the other for version 3.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-01-06T07:45:02.450Z
Answers: 2020-01-07T03:34:58.833Z
Answers: 2020-01-07T03:34:58.833Z
Answers: conspicillatus
Body: <p>I am struggling to find a reasonable method to detect which of <code>python-pip</code> or <code>python3-pip</code> I should install depending on the contents of the <code>ansible_python</code> fact. This is on Debian and Ubuntu.</p>
  
  <p>Looking at <code>ansible_python</code> contents, I did not see anything that would let me correlate the Python version Ansible uses with the package name used to install <em>that</em> Python version. So even though I could glean the path to the Python executable from the fact I don't see how to determine the package used to install it.</p>
  
  <p>The rationale is trying to avoid hardcoding stuff into my playbook. But failing everything else I'd also be willing to hardcode these <em>assumptions</em> into my playbook. The "best" I've come up with so far was to use the <code>package_facts</code> module to collect the information on installed packages, then use <code>ansible_python.version.major</code> to pick from either <code>python-pip</code> or <code>python3-pip</code>, which still contains the assumptions: 1.) that <code>ansible_python.version.major==2</code> maps to <code>python-pip</code> and <code>ansible_python.version.major==3</code> maps to <code>python3-pip</code> and 2.) that <code>ansible_python.executable</code> does name either of the <em>packaged</em> Python versions available in the <code>python</code> and <code>python3</code> packages respectively.</p>
  
  <p>Is there an objectively better way? Better isn't meant to elicit opinions here, anything getting rid of the implied assumptions qualifies as objectively better.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-14T14:04:42.600Z
Comments: I don't think there's a great way to do this. Package naming is going to vary across distributions and across distribution versions. Probably easier to maintain a static mapping of distribution and version to appropriate pip package name, or better yet just document the requirement external to your playbooks.
Comments: larsks
Comments: CC BY-SA 4.0
Comments: 2019-12-14T21:35:30.093Z
Comments: @larsks I only care about Debian derivatives, so concerning the naming across distros I think it'll be fine. But thanks a lot for the input. I'll stick with the way I am doing it right now and add some assertions for good measure. Perhaps there will be an answer in the future, so I'll defer to the community to close and/or delete it.
Comments: 0xC0000022L
Tags: <ansible><linux>
Title: How to determine which packaged pip to install in order to run the Ansible pip module?
UserDisplayName: 0xC0000022L
ThreadText: # How to determine which packaged pip to install in order to run the Ansible pip module?
  
  (Asked by: username_0 on 2019-12-13)
  
  I am struggling to find a reasonable method to detect which of `python-pip` or `python3-pip` I should install depending on the contents of the `ansible_python` fact. This is on Debian and Ubuntu.
  
  Looking at `ansible_python` contents, I did not see anything that would let me correlate the Python version Ansible uses with the package name used to install *that* Python version. So even though I could glean the path to the Python executable from the fact I don't see how to determine the package used to install it.
  
  The rationale is trying to avoid hardcoding stuff into my playbook. But failing everything else I'd also be willing to hardcode these *assumptions* into my playbook. The "best" I've come up with so far was to use the `package_facts` module to collect the information on installed packages, then use `ansible_python.version.major` to pick from either `python-pip` or `python3-pip`, which still contains the assumptions: 1.) that `ansible_python.version.major==2` maps to `python-pip` and `ansible_python.version.major==3` maps to `python3-pip` and 2.) that `ansible_python.executable` does name either of the *packaged* Python versions available in the `python` and `python3` packages respectively.
  
  Is there an objectively better way? Better isn't meant to elicit opinions here, anything getting rid of the implied assumptions qualifies as objectively better.
  
  **Tags:** ansible, linux
  
  > **Comments:**
  > **username_1**: I don't think there's a great way to do this. Package naming is going to vary across distributions and across distribution versions. Probably easier to maintain a static mapping of distribution and version to appropriate pip package name, or better yet just document the requirement external to your playbooks.  
  > **username_0**: @username_1 I only care about Debian derivatives, so concerning the naming across distros I think it'll be fine. But thanks a lot for the input. I'll stick with the way I am doing it right now and add some assertions for good measure. Perhaps there will be an answer in the future, so I'll defer to the community to close and/or delete it.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2020-01-06. Score: 1
  
  There are two options either you make sure you use the same Python version on each host or you make sure the right packages are installed on each platform.
  
  ## Chose same Python interpreter
  
  Provide the python binary to use. Since you have a Debian on each host, the location is always the same. If you know a Python version that is available on each host, go for this.
  
  Either in your inventory `hosts`
  
  ```
  [webserver]
  srv1.example.com
  srv2.example.com
  
  [webserver:vars]
  ansible_python_interpreter=/usr/bin/python3
  
  ```
  
  Or in your Ansible configuration `ansible.cfg`
  
  ```
  ansible_python_interpreter=/usr/bin/python3
  
  ```
  
  See also <https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html#using-python-3-on-the-managed-machines-with-commands-and-playbooks>
  
  ## Package per Python version
  
  If you do not know whether either Python 3 or 2 is available on each host, ensure to get the right package for each Python version.
  
  ```
  - apt:
      name: python-pip
    when: ansible_python.version.major==2
  
  - apt:
      name: python3-pip
    when: ansible_python.version.major==3
  
  ```
  
  You may face the same issue when installing Python packages. So you can put your Pythone version specific tasks in a v2 and in a v3 file and conditionally include one for version 2 and the other for version 3.
  
  
  ---
  
  