Figure out how to best leverage pip in devinabox

[brettcannon]

BPO	21012
Nosy	@brettcannon, @ncoghlan, @bitdancer, @dstufft

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-05-08.20:11:22.272>
created_at = <Date 2014-03-21.16:59:22.419>
labels = []
title = 'Figure out how to best leverage pip in devinabox'
updated_at = <Date 2016-05-08.20:11:22.271>
user = 'https://github.com/brettcannon'

bugs.python.org fields:

activity = <Date 2016-05-08.20:11:22.271>
actor = 'brett.cannon'
assignee = 'none'
closed = True
closed_date = <Date 2016-05-08.20:11:22.272>
closer = 'brett.cannon'
components = []
creation = <Date 2014-03-21.16:59:22.419>
creator = 'brett.cannon'
dependencies = []
files = []
hgrepos = []
issue_num = 21012
keywords = []
message_count = 3.0
messages = ['214390', '214392', '265163']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'ncoghlan', 'r.david.murray', 'dstufft']
pr_nums = []
priority = 'low'
resolution = 'third party'
stage = 'needs patch'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue21012'
versions = []

[brettcannon]

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?

[dstufft]

Right now you can do pip install --download some/path --no-use-wheel <stuff> and then pip install --no-index --find-links some/path <stuff>

In the future that'll be pip download instead probably.

[brettcannon]

Devinabox has moved to its own project at python/devinabox#3