deal with pre-existing build dirs #865

merged 2 commits into from Apr 20, 2013

3 participants


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 #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)

@qwcode qwcode referenced this pull request Mar 27, 2013

pip 1.4 #859

@qwcode qwcode was assigned Mar 29, 2013
@pnasrat pnasrat commented on an outdated diff Mar 30, 2013
unpack = True
url = None
- if not os.path.exists(os.path.join(location, '')):
+ #if a checkout exists, it's unwise to keep going
pnasrat added a line comment Mar 30, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Minor nit then looks good to merge.


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.
then I was going to shout out for more votes.

Python Packaging Authority member

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.

Python Packaging Authority member

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?


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.

Python Packaging Authority member

I am +1 for pip-build.

@hltbra hltbra commented on the diff Apr 1, 2013
+ requirement_set.install(install_options, global_options, root=options.root_path)
+ installed = ' '.join([ for req in
+ requirement_set.successfully_installed])
+ if installed:
+ logger.notify('Successfully installed %s' % installed)
+ elif not self.bundle:
+ downloaded = ' '.join([ for req in
+ requirement_set.successfully_downloaded])
+ if downloaded:
+ logger.notify('Successfully downloaded %s' % downloaded)
+ elif self.bundle:
+ requirement_set.create_bundle(self.bundle_filename)
+ logger.notify('Created bundle in %s' % self.bundle_filename)
+ finally:
+ # Clean up
+ if (not options.no_clean) and ((not options.no_install) or options.download_dir):
Python Packaging Authority member
hltbra added a line comment Apr 1, 2013

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

qwcode added a line comment Apr 4, 2013

yes, let me look into that.

qwcode added a line comment Apr 20, 2013

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 added a line comment Apr 20, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Python Packaging Authority member

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


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).

@qwcode qwcode merged commit 08ca8fa into pypa:develop Apr 20, 2013

1 check passed

Details default The Travis build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment