Probably the most complicated bit now for using devinabox is building the various bits of docs in a way that doesn't require mucking with the system python:

* Having Python built
* Creating a venv
* Installing sphinx
* Running the requisite Makefile with the proper envvar overridden to point to the venv

I see a couple of ways of handling this:

* Assume people know how to do the above
* Verbally instruct people on how to do these steps
* Provide a requirements.txt file for sphinx and coverage -- two birds w/ one stone =) -- and instruct on how to install from that
* Provide a setup_venv script and then instruct on the doc building
* Provide a build.py script which takes named commands like 'docs', 'peps', etc. and then does the right thing automatically

There is also the question of whether any of this should make its way up into the devguide, etc.

My gut says that we should rename README to SPRINT_LEADERS and then provide a README for the sprint participants which lays out the commands along with comments on where to learn more about what's going on. We don't have to advertise that the doc is actually a shell script that we can use to verify the steps are all correct. =) This way they have to grasp the concept of how to build, make a venv, use pip, etc. We can also make sure that there are no documentation holes outside of devinabox for any one step.

Another way to utilize pip is to use it to download all the files necessary to build the docs and get coverage so that offline installations can occur. Not sure what's the easiest way to make pip just download projects and their deps in a way that allows for easily pointing pip at something and say "install from here", but I suspect there's a way (using just wheels is a little tricky as markupsafe has an accelerator and coverage has to be compiled).

IOW how do we get contributors using venv and pip effectively w/o training them only on how to do things in a devinabox instance?