“Did you solve the problem of being able to hack on ansible while running it directly from checkout?”
Not sure what this part was referring to. source ./hacking/env-setup solves this trivally though, and is our recommended answer.
This is because Ansible is not just a Python library – it also cares about data and configuration files and more – and this script sets all of that up.
To be honest, right now I don’t understand the value in setuptools. It’s different, but it’s not a part of core Python.
Ansible isn’t intended to be a library, it’s an application – so the mechanism by which it is built shouldn’t matter to folks.
If you do want to import the API though, you totally can, and you can use the callback classes to extract output.
As for API usage, I’m not sure what the problem is – but for most people they shouldn’t be dealing with the internal API anyway. You could implement an API calling use of Ansible, but you’d be better off 95% of the time to shell out to the program and use a callback plugin. There will be much less code to write.
If GPL is a concern, and it might, there’s a really nice product in Tower for that that gives you a language agnostic REST API.
I’m not shutting this idea down, but I need a coherent explanation as to why this is better, and why someone should need to install setuptools in order to build Ansible.
Yes, setuptools is trendy among some, but it’s not stock Python, and I don’t understand the core problem that needs to be solved here.
It tends to feel like – most of the time, someone has just read “setuptools is better” on the internet, and that’s kind of a silly thing.
I’ve definitely written lots of scripts that import Ansible and use it fine – in fact, /usr/bin/ansible-playbook and /usr/bin/ansible are two of them 
–Michael