# ERROR: invalid-extension: Official Ansible modules must have **URL:** \ **Category:** Project Discussions\ **Tags:** ansible-test\ **Created:** [May 10, 2024, 5:11am UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719 "2024-05-10T05:11:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ddimatos](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ddimatos/32/1040_2.png) [@ddimatos](https://forum.ansible.com/u/ddimatos)\ **Post date:** [May 10, 2024, 5:11am UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719/1 "2024-05-10T05:11:56Z")
Hi, I recently encountered: ```auto ERROR: invalid-extension: Official Ansible modules must have a .py extension for python modules or a .ps1 for powershell modules ``` This came with this PR [here](https://github.com/ansible/ansible/pull/82628/files#diff-5d587800b7a45ed191c51b23475d49c9ec4812e44b49b86a9c59a89f45c5860dR30) Documentation for a module currently [says](https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#preparing-an-environment-for-developing-ansible-modules) ```auto Preparing an environment for developing Ansible modules You just need ansible-core installed to test the module. Modules can be written in any language, but most of the following guide is assuming you are using Python. Modules for inclusion in Ansible itself must be Python or Powershell. One advantage of using Python or Powershell for your custom modules is being able to use the module_utils common code that does a lot of the heavy lifting for argument processing, logging and response writing, among other things. ``` It’s unfortunate that the languages for inclusion are limited to Python and Powershell, and I understand why, **but why make this an error vs a warning**? There are collections that are writing modules in other languages because some platforms don’t come with Python (yet) and to ensure a users first experience with using Ansible on a particular platform, they may offer something like `ping` in a platforms available language, in my case that is REXX. Which results in: ```auto ERROR: Found 2 validate-modules issue(s) which need to be resolved: ERROR: plugins/modules/zos_ping.rexx:0:0: invalid-extension: Official Ansible modules must have a .py extension for python modules or a .ps1 for powershell modules ERROR: plugins/modules/zos_ping.rexx:0:0: python-syntax-error: Python SyntaxError while parsing module ``` I could create a `ignore-2.xx.txt` file but then have to justify the ignore entry. Any thoughts about removing this ansible-test error or reducing it to a warning? ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [May 10, 2024, 7:54am UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719/2 "2024-05-10T07:54:04Z")
(I moved this from Get Help to Project Discussions. Also pinging @mattclay.) I think having this error by default is good for most collections, since 99% of the collections only have Python and/or PowerShell modules. But it would be great if it could be disabled via the ansible-test config file ([ansible/test/lib/ansible\_test/config/config.yml at devel · ansible/ansible · GitHub](https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/config/config.yml)) for collections that _do_ have modules in other languages. Having to list all modules in tests/sanity/ignore-\*.txt is annoying. (Making it possible to globally disable the `missing-gplv3-license` error for modules would also be great, this one is really annoying for collections whose modules use a difference license.) ---
**Author:** ![ddimatos](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ddimatos/32/1040_2.png) [@ddimatos](https://forum.ansible.com/u/ddimatos)\ **Post date:** [May 10, 2024, 1:54pm UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719/3 "2024-05-10T13:54:39Z")
> [@felixfontein](#): > > `missing-gplv3-license` error The `missing-gplv3-license` error disablement would be great as well, we have over 20 modules we maintain those license ignore entries, and collectively, over 60 modules for our organization. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [May 13, 2024, 4:03pm UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719/4 "2024-05-13T16:03:39Z")
We don’t really have any current plans for extending ansible-test for more flexible collection testing at this time. The original reason that ansible-test became the standard for testing collections was largely because nothing else existed, so collections inherited the same rules as ansible-core. Our goal going forward is basically to stop adding new testing functionality for collections to ansible-test, and move the ansible-test included with core back to only testing core. Which will require that we get another team on board with forking ansible-test to solely support collections, or to implement different tooling for the long term support of collections. In theory we have this agreement in place, but no timelines, work, discussions, or architecture have happened as of yet. ---
**Author:** ![ddimatos](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ddimatos/32/1040_2.png) [@ddimatos](https://forum.ansible.com/u/ddimatos)\ **Post date:** [May 13, 2024, 8:52pm UTC](https://forum.ansible.com/t/error-invalid-extension-official-ansible-modules-must-have/5719/5 "2024-05-13T20:52:36Z")
Thanks @sivel , understood, I will let the Ansible partners know that our ignore text entries will continue on for some time. Just today I was looking back at ansible-test that came with 2.9, which at the time had 44 tests and the ‘latest’ has 32; I had thought this was a result of more being put into `ansible-lint` but your explanation summarizes it well. How does ansible-lint fit into any of this in terms of focusing more on collections instead of ansible-test?