Failed to import the required Python library on VM's Python /usr/bin/python

[TafkaMax]

Describe the bug

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ModuleNotFoundError: No module named 'phpypam'

I am using Debian 12 and PIP is not allowed to install packages globally. Before I used pip install phpypam globally and it worked.

Now I have created a venv on the my ipam VM. When running my ansible-playbook from a controller node. I get this message, even though I try to set ansible_python_interpreter.

changing ansible_python_interprer the command 'which python' always returns /usr/bin/python on the ipam VM, instead of the venv python.

The flow of using ansible:

Controller (Uses Venv with ansible installed e.g. ~/git-repo/with-playbook/venv/bin/activate) -> IPAM VM ( Has /opt/docker_venv/bin/python that I set with the ansible_python_interpreter)

To Reproduce

I tried to change the python_interpreter to use different python version on the ipam VM. NB! the interpeter venv path is the one in the VM not in the controller. I am not sure how it works. which version of python it uses?

Expected behavior

Use correct venv.

Versions:

• Ansible:
• phpipam-ansible-modules:
• phpypam:
• phpIPAM:

Additional context
Add any other context about the problem here.

[TafkaMax]

If I install it in system pip it works, because it does not respect the virtualenv or the controller modules.

pip install phpypam --break-system-packages

[TafkaMax]

Hmm I was thinking I need to rewrite my modules to work on the controller only. Because they are API calls not things strictly inside the VM?

[cmeissner]

Hi @TafkaMax

thank you for filling this issue. We do not see that this is an issue of our modules. It seem to be related to how ansible will work in venvs instead. As we develop our modules completely isolated from system python by using pyenv we also don't agree that our modules can't run in virtual envs.

I would suggest to convert this issue to dicussions as it is not directly related to any bug in our code.

[TafkaMax]

Yes I agree. In the end because the calls are made through the API it works with delegate_to: localhost

So the issue is solved. I just needed to rethink the usage logic.

[cmeissner]

Yay, if you see the inventory of our test suite you see that we always work with localhost. You delegate_to is another option.