Yeah, this old chestnut.
So I was working on packaging Ansible for distribution @ my job and I was reminded about this PR I submitted a while back:
https://github.com/ansible/ansible/pull/10122, the key takeaway being: https://github.com/sixninetynine/ansible/blob/bf6b43dd71a29e3c2a44fd425cf36c0528f40cc7/setup.py
As per the PR and links in the PR, this was going to be considered in V2, but there seemed to be some hesitation on testing/usefulness. I wanted to open a dialog on the usefulness by offering an example:
In my environment, we have an inventory system that requires results to be scoped based on a query language (real world example: %datacenter.servicename.instancenumber), so our dynamic inventory script requires some environment variables to be set (we use the host-pattern). I want my team and myself to be able to use Ansible as close to upstream as possible (if not pure ansible codebase, then at least usage matching that of the documentation). In order to achieve this we’ve done a few workarounds:
- ansible () {
- env ANSIBLE_QUERY_TYPE=host ANSIBLE_QUERY=$1 $(/usr/bin/which ansible) “$@”
- }
Or adding a header to all the bin/ansible* scripts that patches via os.environ.update():
`
∴ ld ~/src/ansible-ull_trunk $ head bin/ansible
#!/usr/bin/env python
before official ansible, we patch the users env
from linkedin.ansibleull.header import env_init
env_init()
So here’s my question:
Anyone else need this?
I hesitate to say “HEY LET’S VOTE” but it would be good to get a sense that others might find this useful.
Not needing it atm, but imho it would be a good practice to do that.
A next step would then be to use a bit more functions in the cli/ modules.
People wanting to write a custom wrapper script will then be able to maintain that more easily.
Serge
Oops, originally sent this just to loren. Forwarding to ansible-devel now 
Cool! I actually like the sound of this more
It would be a good opportunity to standardize the option parsing between the scripts too (ansible using the ‘Cli’ object vs ansible-playbook using main(), etc)
Hey Toshio,
I hacked on this a bit this weekend but my 8 month old distracted me before I could get anything of value – then earlier today I noticed in the v2 todo doc that James posted there was this note:
- Move to classes, generalize code
Does this mean any work here would be redundant?
thanks
Not redundant necessarily, but it's on the roadmap... bcoca has been
doing some work on this in the last few days:
https://github.com/ansible/ansible/pull/10885
but it doesn't go as far as I think you were hoping for. His tree is
pulling code into classes, the step that would get to where you want
would be to push all of those classes into a new module (something
like v2/ansible/cli/{__init__.py, galaxy.py, ad_hoc.py, playbook.py,
vault.py} ). Talking to bcoca about what he's working on would
definitely be fruitful.
-Toshio
Hey, just took a gander at the ansible.ansible.cli module and it’s actually exactly what I want!
Just gotta wait until v2 and I’ll be a happy camper!