# Composability: is there a way to implement a module as a series of ansible tasks?

**URL:** <https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025>\
**Category:** Ansible Project\
**Created:** [August 15, 2015, 5:00am UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025 "2015-08-15T05:00:09Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![cohen.ben](https://avatars.discourse-cdn.com/v4/letter/c/c89c15/32.png) [@cohen.ben](https://forum.ansible.com/u/cohen.ben)\
**Post date:** [August 15, 2015, 5:00am UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025/1 "2015-08-15T05:00:09Z")

</div>

I really like the ansible module interface: pure functions are powerful, super simple and really great. The with\_items syntax adds a lot of power on top with very low cognitive overhead that helps keep you laser focused on describing your objectives in ways that tend to be very declarative.

Sometimes though, I’ve got a task that I need to do multiple times but can’t express as a single module call – or I might find myself needing to do something somewhat tricky in multiple different places and I’d like to avoid repeating the complexity. I use the the roles/ system heavily to try and reduce repetition, however some things just aren’t easily refactored into roles or its very awkward to do so and increases the cognitive overhead of understanding the overall objective.

Does a mechanism exist which makes it possible to basically package up a sequence of tasks as a module?

It would be (really really) cool if I could package up a sequence of tasks as a custom module. I imagine a syntax like this:

inside library/copyAndDecrypt.yml

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [August 15, 2015, 5:06am UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025/2 "2015-08-15T05:06:42Z")

</div>

that is what includes and roles are for.

---

<div class="post-metadata">

**Author:** ![cohen.ben](https://avatars.discourse-cdn.com/v4/letter/c/c89c15/32.png) [@cohen.ben](https://forum.ansible.com/u/cohen.ben)\
**Post date:** [August 15, 2015, 5:40am UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025/3 "2015-08-15T05:40:47Z")

</div>

Ok – I see that include: supports with\_items in ansible v2 – I think I see that include: + blocks: get me most of what I want. Will (does already?) include: have an option in v2 to limit the scope of the included tasks to only the values passed in and to not leak variables registered within out to the caller? It seems like include: and with\_items: could become confusing without this …

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [August 15, 2015, 1:53pm UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025/4 "2015-08-15T13:53:53Z")

</div>

no var scoping, but just using simple naming conventions should deal with that.

---

<div class="post-metadata">

**Author:** ![cohen.ben](https://avatars.discourse-cdn.com/v4/letter/c/c89c15/32.png) [@cohen.ben](https://forum.ansible.com/u/cohen.ben)\
**Post date:** [August 16, 2015, 6:56am UTC](https://forum.ansible.com/t/composability-is-there-a-way-to-implement-a-module-as-a-series-of-ansible-tasks/19025/5 "2015-08-16T06:56:02Z")

</div>

It works in the example I gave yes – but it seems like any task with both when: and register: becomes basically impossible to reason about within an include … (the registered value could come from a previous include: invocation in the case of when: evaluating to false) …
