How to find Ansibles depenencies?

Get Help
1

Hi,

tl;dr: How to find (list) ansibles dependecies? For example, it needs python3-apt (which seems to be a very specific package, that cannot be installed manually) - but what else?

detailed:
I looked to the ansible-core support matrix and learned that my target python must be an old one. I used pyenv to install python 3.9 on managed node, that same I have on the control node, and configured it as interpreter. I start with a simple apt update (see at the end) but end up with:

TASK [Update apt packages] ************************************************************************************************************************************************************************************
[WARNING]: Updating cache and auto-installing missing dependency: python3-apt
fatal: [c3-999]: FAILED! => {"changed": false, "msg": "Could not import python modules: apt, apt_pkg. Please install python3-apt package."}

Now apparently python3-apt can neither be installed via pip, nor the system one can be used (of course it is installed globally using apt install python3-apt).

I also try the python3.11 using apt install python3.11 (and set the ansible_python_interpreter=/usr/bin/python3.11), but get the same error.

Let me assume I somehow solve that, possibly with help of the community here :), or rewriting using shell commands. Then I’m afraid that I just get stuck at the next unmeet dependency.
Is there a list of dependencies I need to fullfil in order to use the ansible-2.10.7+merged+base+2.10.8+dfsg-1 that came with Debian 11 / bullseye?

Also, I manage some nodes that have no original Debian linuxes.

Any pointers appreciated!

- hosts: nodes
  gather_facts: no
  become: true
  tasks:
  - name: Update apt packages
    apt:
      update_cache: yes
      cache_valid_time: 3
2 Likes
2

I would use the system python interpreter. So instead of pyenv python, point Ansible to your system python that matches your python3-apt.

3

ansible_python_interpreter: /usr/bin/python3

4

Hi,

thank you for your quick reply.

As I wrote, this does not work, since my Ansible needs an old Python, so I try to provide one - and now need to also provide additional dependencies, which I do not know yet.

1 Like
5

tl;dr: How to find (list) ansibles dependecies?

You can find the list of requirements for each plugin in their documentation, for the apt module it’s ansible.builtin.apt module – Manages apt-packages — Ansible Community Documentation

Now apparently python3-apt can neither be installed via pip , nor the system one can be used (of course it is installed globally using apt install python3-apt ).

Unfortunately the apt module depends on the apt Python bindings that are only available for the system Python which you have to use in order to run the apt module. The same case applies to e.g. the dnf module. Fortunately this is being worked on, see Ansible supported Python version on _target_ - #17 by Thulium-Drake.

As I wrote, this does not work, since my Ansible needs an old Python

As @nsavich already said, there’s no other way than to set ansible_python_interpreter to the system Python that has the apt bindings in order to use the module. I am curious what is the system Python version that your ansible-core version doesn’t support?

Another alternative is to pip install different ansible-core version that satisfy your environment.

3 Likes
6

You can find the list of requirements for each plugin in their documentation

Ahh, thank you. builtin.apt is a plugin?
The docs say:

Thank you for your quick, helpful and detailed reply!

This module is part of ansible-core and included in all Ansible installations… ansible.builtin.apt …

I always thought there are builtins at one hand and plugins at the other.

However, since it is core and it is needing python3-apt, this means core needs python3-apt - and so “ansible-core support matrix” should mention this dependency, shouldn’t it?

How to I find what other plugins I accidentally use?

Unfortunately the apt module depends on the apt Python bindings that are only available for the system Python which you have to use in order to run the apt module

Yes, I’ve read that. Interestingly, it seems hard to built it from source. So I think this won’t be my best option. If it is just apt, I can rewrite to shell commands I think. But after reading the link you shared (thank you), I’m afraid my issue is bigger; Ansible evolved a lot since I started using it and I may need to look for alternatives that are more portable (surely for the price of less functionality) or have a “ansible farm”, for example several containers sharing the scripts.

Isn’t having several Linux nodes in different versions a common use case? How to address this? Maybe there is some tutorial giving me a starting point?

Another alternative is to pip install different ansible-core version that satisfy your environment.

Yes, maybe there is a core version that supports my control node python version as well as all my target node versions for the moment, and I could install it - but then my script probably will not work anymore… Also, I’m afraid this will break in future when there will be no single Ansible version supporting all my targets (which possibly already is the case, for certain reasons I have multiple control nodes at the moment and actually planned to join them, which would not work out I think).

When having several Linux nodes in different versions, how to address this? Maybe there is some tutorial giving me a starting point?

7

Right now you need to use an old enough ansible-core version to be able to install packages on older Debian/Ubuntu systems (same for Rocky/Alma/CentOS/RHEL/…) This will hopefully change in the future, see CfgMgmtCamp 2026 discussion (1/12): Supported Python versions, or: supporting older Operating Systems, but it will likely take some time until that’s the case.

1 Like
8

Right now you need to use an old enough ansible-core version to be able to install packages

Do you think apt could be my only issue? I think this I could easily replace by command: “apt -y install” (actually had this in the past).

How are you operating Ansible? I think I should have several versions in parallel. Would schroot help? I consider containers, but usually I manage containers with Ansible :slight_smile:

9

I’m currently in the situation that I only have to manage systems that have a new enough system Python with ansible. (Though there is at least one Rocky 8 system I’d like to manage partially with ansible as well, but currently can’t because I’m always sticking to the latest ansible release.)

The easiest way forward is to pick one version of ansible-core that supports all system Python’s you have on your targets - if a single version exists that supports all of them. (The support matrix is very useful for determining this.)

10

Thank you for your input, yes, I was looking at this.

If only apt (and possibly dnf) is the big problem, I can use pyenv + python_interpreter via inventory to use a common python and shell based apt. But this is empirical and thus a risk - maybe tomorrow I find a scirpt that fails somewhere else. Such issues can quickly take hours which may not be available in all cases.

The support matrix is very useful for determining this.

I’m afraid, unfortunately it is not. It claims it would list core dependencies and the depenecies look small, but things like “ansible.builtin.apt” are not builtin core functionalities but technically are plugins with own dependencies:
each needed builtin plugin need to be checked as well.

This is a bit unfortunate, I had choosen Ansible mostly because it had no big requirements on target nodes, but apparently this changed over the years.

Which at first may suprise people, I asked in my team and everybody said it is surprising, most assumed “builtin” and “plugin” are mutually exclusive : a package is either built‑in OR it is a plugin. But here they are both.

To get the dependencies, someone additionally needs to iterate all builtin plugins, look up each dependencies and then see what is availble. So far I did not really manage what node needs which ansible script (because I falsely assumed, buildin will always work, and I didn’t pay attention to depenencies nor documented it sooo well).

Well, and so I asked here if there is a better way than manually checking each script for each used builtin plugin and look it up.

(I have also certain specialized linuxes, like heavily down-stripped, specialized Devuan VMs that start within 12 seconds or so - the downstrip could remove things that are used by Ansible scripts. Currently I deploy using image replacements without Ansible, but I like to have Ansible available in case I need quick global updates)

11

I think the word “plugin” is misunderstood. A plugin is anything listed and loaded by the PluginLoader. Everything in ansible.builtin is a plugin. It does not mean it is not part of core.

12

This use of “plugin” isn’t specific to Ansible btw, I’ve also seen other programs having builtin plugins and some that can be separately installed.

You should have quoted the “this” part I wrote: finding an ansible-core version that supports the system Python. The system Python version depends on the operating system, and if you write down all OSes you want to support and their system Python versions, the matrix is the best thing you have to figure out which ansible-core version covers them all (or if there is none which can - versions newer than the latest one listed as supported might also work fine, just older ones usually don’t).

Figuring out dependencies for plugins is something totally unrelated to figuring out an ansible-core version that is compatible with system Python interpreters of OSes. And obviously (as you wrote) that can’t be done with that matrix (and the matrix is also not intended for that).

This is a bit unfortunate, I had choosen Ansible mostly because it had no big requirements on target nodes, but apparently this changed over the years.

I think that the builtin plugins still have the same requirements they had 5 or even 10 years ago (with maybe very few exceptions). The apt and dnf/yum plugins always required the Python bindings of the respective package managers. Also the apt module automatically installs the bindings if they aren’t available (ansible.builtin.apt module – Manages apt-packages — Ansible Community Documentation - the configuration was only added in 2.19, the module was simply always doing that before).

What did change over time is the set of supported Python versions on the target node.