"couldn't resolve module/action 'vagrant'" error when installing molecule-plugins in a fresh environment

[garar]

Hello!

I'm trying to install molecule-plugins into fresh Python 3.12 venv using pipx (Ubuntu 24.04).

Basically what I do is:

pipx install --python python3.12 --include-deps 'molecule-plugins[vagrant,docker]'

But when I try to run molecule verify using vagrant I get:

> molecule converge && molecule verify
WARNING  Driver vagrant does not provide a schema.
INFO     default scenario test matrix: dependency, create, prepare, converge
INFO     Performing prerun with role_name_check=0...
INFO     Running default > dependency
WARNING  Skipping, missing the requirements file.
WARNING  Skipping, missing the requirements file.
INFO     Running default > create
ERROR! couldn't resolve module/action 'vagrant'. This often indicates a misspelling, missing collection, or incorrect module path.

The error appears to be in '/home/garar/.local/share/pipx/venvs/molecule-plugins/lib/python3.12/site-packages/molecule_plugins/vagrant/playbooks/create.yml': line 8, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  tasks:
    - name: Create molecule instance(s) # noqa fqcn[action]
      ^ here

This is pip list output for my env:

Package                   Version
------------------------- ---------
ansible-compat            25.1.1
ansible-core              2.18.2
attrs                     25.1.0
bracex                    2.5.post1
certifi                   2025.1.31
cffi                      1.17.1
charset-normalizer        3.4.1
click                     8.1.8
click-help-colors         0.9.4
cryptography              44.0.0
distro                    1.9.0
docker                    7.1.0
enrich                    1.2.7
idna                      3.10
Jinja2                    3.1.5
jsonschema                4.23.0
jsonschema-specifications 2024.10.1
markdown-it-py            3.0.0
MarkupSafe                3.0.2
mdurl                     0.1.2
molecule                  25.2.0
molecule-plugins          23.7.0
packaging                 24.2
pip                       25.0
pluggy                    1.5.0
pycparser                 2.22
Pygments                  2.19.1
python-vagrant            1.0.0
PyYAML                    6.0.2
referencing               0.36.2
requests                  2.32.3
resolvelib                1.0.1
rich                      13.9.4
rpds-py                   0.22.3
selinux                   0.3.0
subprocess-tee            0.4.2
typing_extensions         4.12.2
urllib3                   2.3.0
wcmatch                   10.0

I'm not sure if this is a problem with molecule-plugins, or molecule itself.

I believe there is no problem with my setup in general, because if I install old ansible, molecule and molecule-plugins it does work. This is what works:

"ansible<10.0.0,>=9.1.0",
"molecule[testinfra]<7.0.0,>=6.0.3",
"molecule-plugins[vagrant]<24.0.0,>=23.5.0",
"ansible-lint>=24.10.0",

Is there some kind of compatibility matrix for molecule-plugins, molecule and ansible?

Thanks!

[tkimball83]

I ran into this today trying to get a fresh environment going. Unfortunately the latest version of molecule seems to introduce this error. While you wait for this issue to be investigated, the following version combination got me going.

ansible>11,<12
molecule==25.1.0
molecule-plugins==23.7.0

[garar]

Hi @tkimball83 !

Your combination works, thanks!

Still, it would be great to have it working by default with newest versions.

[hswong3i]

This most likely due to ansible/molecule#4380

[apatard]

@hswong3i possibly. I wanted to find time to double check this assertion but failed so far. After merging the PR to use molecule >= 25.1.0, @ssbarnea mentioned that it was not necessary a good idea as there was possible breakages soon. Looks like it was sonner than I expected. We should possibly require only 25.1, while waiting for the dust to settle ?

[hswong3i]

@apatard please see my comment on ansible/molecule#4380 (comment)

Once I revert this PR my CI case working fine again:

• alvistack/ansible-community-molecule@19a4df1
• https://build.opensuse.org/package/show/home:alvistack/ansible-community-molecule-25.2.0

[sebastiankoeniggit]

@tkimball83

I ran into this today trying to get a fresh environment going. Unfortunately the latest version of molecule seems to introduce this error. While you wait for this issue to be investigated, the following version combination got me going.

ansible>11,<12
molecule==25.1.0
molecule-plugins==23.7.0

Thank you so much!

I was bashing my head against the wall for hours bc I was getting one error after the error.

With you setup everything just works.

Thank you. Seriously!

[matthijs-oosterhoff]

I ran into this issue too. The workaround of downgrading molecule did resolve the issue, but that's not a permanent solution.

@hswong3i 's comment brought met to https://ansible.readthedocs.io/projects/dev-tools/user-guide/test-isolation/#isolated-mode-virtual-environment-default, which states the recommended installation of molecule is through the ansible-dev-tools package.

When running the tools from ansible-dev-tools in a venv, the environment should be set automatically.

I switched my setup to use this package and now molecule+vagrant works fine, and that's with molecule 25.2.0.

Edit:

Sadly, I just found out this is not the case. I had set the ANSIBLE_LIBRARY environment variable while tinkering and that had fixed the issue. It seems this variable should point to something like <your_venv>/lib/python<version>/site-packages/molecule_plugins/vagrant/modules for molecule to pick up the Vagrant module.

[r-pufky]

I ran into this today trying to get a fresh environment going. Unfortunately the latest version of molecule seems to introduce this error. While you wait for this issue to be investigated, the following version combination got me going.

ansible>11,<12
molecule==25.1.0
molecule-plugins==23.7.0

Confirmed, same issue / resolution on manjaro.

pip install --force-reinstall -v 'molecule==25.1.0' fixes for temporary workaround.

Could we also add a regression test to ensure this doesn't break on a release unintentionally again?