ansible_env is undefined

Archives Ansible Project
1

After upgrading ansible versions:

ncohen@breathe ~/s/f/fn-ansible (master)> ansible --version

ansible 2.0.1.0

config file = /Users/ncohen/software/face/fn-ansible/ansible.cfg

configured module search path = Default w/o overrides

I’m getting an error on first usage of ansible_env variable

- hosts: local
environment:

PATH: "{{ ansible_env.PATH }}:/usr/local/bin"
tasks:
...

Error looks like this:

PLAY ***************************************************************************

TASK [setup] *******************************************************************

fatal: [localhost]: FAILED! => {"failed": true, "msg": "'ansible_env' is undefined"}

NO MORE HOSTS LEFT *************************************************************

to retry, use: --limit @<snip>

PLAY RECAP *********************************************************************

localhost : ok=0 changed=0 unreachable=0 failed=1

Anyone have any idea what’s going on? This worked on 2.0.0.1 without issue …

2

As per https://github.com/ansible/ansible/blob/devel/CHANGELOG.md

“Fix to make implicit fact gathering task correctly inherit settings from play, this might cause an error if settings environment on play depending on ‘ansible_env’ which was previously ignored”

3

Thanks – what’s a good pattern to the PATH environment variable during a play?

4

There are a lot of good reasons you might want to only change the search path rather than “set” it. And there are also reasons you might want to have this mutated value for an environment variable be used only in the context of a playbook run.

It would be very convenient to be able to augment the environment variables for a play (rather than only set) … Could ansible support something like this maybe?

environment:
PATH:“$PATH:/some/special/searchdir/for/this/play/”

The alternatives I can see are:
(1) repeat yourself a whole lot with environment declarations per task
(2) mutate the environment variable via the underlying shell environment initialization system.
(3) fully specify the values for the mutated variable …

The first option requires lots of repetition. The second option spreads the mutation requirements to other aspects of the system rather keeping this changed behavior localized within the playbook execution context – frequently you might not want this as you might be deliberately only using some alternate search path during a particular play. I’d say there is also a fair amount of not cross-platform ‘make-busy-work’ to actually go through the process of modifying the shell environment variables initialization configuration in a persistent way… Mutating shell environment initialization this way will very probably hide/obscure a pretty meaningful mutation behind someone’s back rather than clearly declaring it up front as part of the play’s execution contract …

Option 3 seems like the only approach that can work. However it’s not as clean to me and requires manually managing the correct default system search PATH values which are not necessarily the same across systems/os/user accounts (etc). Definitely introduces undesirable consequences that are not possible to avoid …