deal with pre-existing build dirs

[qwcode]

redo of pull #712.

addresses issues #413, #709, #634 and #602.

the changes:

1. remove the build dir if there's an exception (unless specifying --no-clean)
2. a new --no-clean option for those who want build dirs left for the sake of analysis
3. fail with an exception if there's a pre-existing build dir. just checking the version in the build dir might be considered acceptable, but we changed that check to just warn (and not fail) about 9 months ago for specific reasons. see pull Only warn for mis-versioned packages. #436.
4. 4 new tests. all are local, and for one of them, since it made sense, I intentionally tried to do the "right" thing and not use just use reset_env, but rather worked at a unit level.

the --no-install/--no-download workflow is not affected by this. this still works as before (w/o using --no-clean)

[pnasrat]

nit add a space between commet and text. Also as per pep8 it should be a sentence with capitalization and a period at the end.

[pnasrat]

Minor nit then looks good to merge.

[qwcode]

this one has some controversy in it, so needs at least 3 votes IMO.
I'm letting stuff build up in the 1.4 milestone right now.
https://github.com/pypa/pip/issues?milestone=1&state=open
then I was going to shout out for more votes.

[hltbra]

A long time ago I changed all pip tests to use unittest.TestCase classes and Ian Bicking was againt that and he told me something like "in my experience global test functions works better because tests are self-contained and you know where to look at". I am not again using test classes, but most of our test code use global test functions.

Maybe we shoud keep that "style". But it is probably going to be more difficult to write this kind of test with global test functions and try/finallys.

Just telling you what Ian told me years ago, not saying "no" to this.

[hltbra]

It always bothered me that we use plain "build" name. Many projects have a "build" directory and it is confusing sometimes.

Does someone have a good idea for naming this directory?

[qwcode]

as for the test class, that's to hold the setup/teardown for that test. and other tests could end up reusing that.

as for the plain "build" name, that's just in virtualenvs (it's /tmp/pip-build-<user> for global pip), but maybe "pip-build"?

to be clear though, "build" as at the root of the virtualenv, and can't conflict with a project src checkout.

[hltbra]

I am +1 for pip-build.

[hltbra]

It would be nice to have tests for the mix of these options.

[qwcode]

yes, let me look into that.

[qwcode]

I'm confused. there'seems to be logic and tests around --download/--noinstall being used together,
but currently it seems --download is the dominant option?
it seems we should just raise a command error that these options do nothing together.
I'll open a separate pull for that and block this pull on that until its sorted out.

[qwcode]

leaving out tests for this and added #907 to be handled in v1.4. will handle testing holes over there.
will just merge this now, and if I'm wrong about #907, can double back and add tests.

[hltbra]

Issue #547 has a different scenario: installing a package in version X, aborting while installation, then try installing the same package in version Y.

Like:

pip install django==1.2.3
# press CTRL-C
pip install django==1.2.4

I think it should not be a problem since this pull request removes the build dir if any exception occur (and CTRL-C/KeyboardInterrupt is an exception).