# Getting a Shippable error importing importing an existing module into a new module.

**URL:** <https://forum.ansible.com/t/getting-a-shippable-error-importing-importing-an-existing-module-into-a-new-module/25087>\
**Category:** Ansible Developer\
**Tags:** aws\
**Created:** [July 26, 2017, 12:31am UTC](https://forum.ansible.com/t/getting-a-shippable-error-importing-importing-an-existing-module-into-a-new-module/25087 "2017-07-26T00:31:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Willem\_van\_Ketwich](https://avatars.discourse-cdn.com/v4/letter/w/8e8cbc/32.png) [@Willem\_van\_Ketwich](https://forum.ansible.com/u/Willem_van_Ketwich)\
**Post date:** [July 26, 2017, 12:31am UTC](https://forum.ansible.com/t/getting-a-shippable-error-importing-importing-an-existing-module-into-a-new-module/25087/1 "2017-07-26T00:31:15Z")

</div>

Hi there,

I’m working on a new module (cloudfront\_distribution) and have started getting an error in the past week with Shippable failing.

The error is shown below:

The test `ansible-test sanity --test import --python 3.6` failed with the following error:

```auto
lib/ansible/modules/cloud/amazon/cloudfront_distribution.py:539:0: ModuleNotFoundError: No module named 'ansible.modules'

```

The error is occurring because I am importing another module (cloudfront\_facts) into this module, specifically the line:

from ansible.modules.cloud.amazon.cloudfront\_facts import CloudFrontFactsServiceManager

I could copy all the methods from cloudfront\_facts into the cloudfront\_distribution module, but my concern with this is twofold:

- There are 18 calls to cloudfront\_facts from cloudfront\_distribution - albeit some calls are to the same functions, but this is still a significant amount of code to be copying verbatim into a second module.
- Adding the duplicate code would also lead to unnecessary code bloat and maintenance, and goes against the DRY coding principle (Don’t Repeat Yourself).

I was wondering if there is a way to prevent this Shippable error without duplicating the code between modules. Is there possibly a file the module can be added to to skip this Shippable test?

There is probably a perfectly valid reason for this test to fail (such as preventing dependency chains) and there may be another alternative, (like placing the common code into module\_utils/aws or module\_utils/facts), but thought I’d open it up for discussion on the best way to approach/fix this.

Thanks,  
Will

---

<div class="post-metadata">

**Author:** ![alikins](https://avatars.discourse-cdn.com/v4/letter/a/d07c76/32.png) [@alikins](https://forum.ansible.com/u/alikins)\
**Post date:** [July 26, 2017, 2:05pm UTC](https://forum.ansible.com/t/getting-a-shippable-error-importing-importing-an-existing-module-into-a-new-module/25087/2 "2017-07-26T14:05:08Z")

</div>

For cases like this, the current approach is to move shared code into a ansible.module\_utils module and update cloudfront\_facts and cloudfront\_distribution

to use the new module\_utils.

Importing ‘from ansible.modules.other\_module’ from my\_module isnt recommended, since ‘other\_module’ wont be available when my\_module is invoked

remotely. The runtime python path for the remote module more or less only has my\_module and ansible.module\_utils available to it.
