# Explicit Include Attribute Inheritance

**URL:** <https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608>\
**Category:** Ansible Developer\
**Created:** [May 23, 2018, 8:21pm UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608 "2018-05-23T20:21:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**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 23, 2018, 8:21pm UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608/1 "2018-05-23T20:21:22Z")

</div>

TL;DR

I’ve put together a Google Form, where you can vote on the implementation you prefer and provide an option for the name of the attribute/keyword:

[https://goo.gl/forms/Q0nORDF7lbrpeGrF2](https://goo.gl/forms/Q0nORDF7lbrpeGrF2)

Read on for more details…

---

<div class="post-metadata">

**Author:** ![Andrew\_Gaffney](https://avatars.discourse-cdn.com/v4/letter/a/71c47a/32.png) [@Andrew\_Gaffney](https://forum.ansible.com/u/Andrew_Gaffney)\
**Post date:** [May 23, 2018, 9:49pm UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608/2 "2018-05-23T21:49:36Z")

</div>

Both of these just seem to be syntactic sugar that’s equivalent to using ‘block’ yourself and don’t seem to add much of anything. There should probably be a third option on the form for people that don’t think that either implementation is a good idea.

---

<div class="post-metadata">

**Author:** ![Mathew\_Boorman](https://avatars.discourse-cdn.com/v4/letter/m/ac91a4/32.png) [@Mathew\_Boorman](https://forum.ansible.com/u/Mathew_Boorman)\
**Post date:** [May 28, 2018, 3:02am UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608/3 "2018-05-28T03:02:38Z")

</div>

Getting a consistent model so users know where the setting should be is key. I’d argue the block fix seems to be more of a workaround for a regression added in 2.5. A block has no logical connection to the includes it contains, so the workaround is unexpected special case behavior when a include is nested inside a block.

That leaves either the keyword, or argument. Since a apply keyword only makes sense for includes, I’m tending towards a argument. The ongoing changes to include mechanisms indicate they is not the stability to justify locking down a keyword yet.

---

<div class="post-metadata">

**Author:** ![Abhijit\_Menon-Sen1](https://avatars.discourse-cdn.com/v4/letter/a/8e7dd6/32.png) [@Abhijit\_Menon-Sen1](https://forum.ansible.com/u/Abhijit_Menon-Sen1)\
**Post date:** [May 28, 2018, 4:29am UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608/4 "2018-05-28T04:29:28Z")

</div>

> A block has no logical connection to the includes it contains, so the

workaround is unexpected special case behavior when a include is nested  
inside a block.

I agree, and it's a nasty surprise for people who don't happen to know this  
special-case.

-- Abhijit

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\
**Post date:** [May 30, 2018, 11:18pm UTC](https://forum.ansible.com/t/explicit-include-attribute-inheritance/27608/5 "2018-05-30T23:18:34Z")

</div>

Tasks inside a block already inherit keywords applied to the block,  
this is normal, documented and intended block behaviour, having it  
cascade on included tasks was always how it was meant to work.

I agree that a new method for include is a syntactic sugar, it would  
be the equivalent of making a block just for the include and applying  
keywords. That said, i can see why users would want to assign those  
via the inlclude itself w/o having to rely on another structure.