New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deal with pre-existing build dirs #865

Merged
merged 2 commits into from Apr 20, 2013

Conversation

Projects
None yet
3 participants
@qwcode
Contributor

qwcode commented Mar 27, 2013

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

Closed

pip 1.4 #859

@ghost ghost assigned qwcode Mar 29, 2013

@pnasrat

View changes

Show outdated Hide outdated pip/req.py
@pnasrat

This comment has been minimized.

Show comment
Hide comment
@pnasrat

pnasrat Mar 30, 2013

Contributor

Minor nit then looks good to merge.

Contributor

pnasrat commented Mar 30, 2013

Minor nit then looks good to merge.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Mar 30, 2013

Contributor

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.

Contributor

qwcode commented Mar 30, 2013

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

This comment has been minimized.

Show comment
Hide comment
@hltbra

hltbra Apr 1, 2013

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.

Member

hltbra commented Apr 1, 2013

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

This comment has been minimized.

Show comment
Hide comment
@hltbra

hltbra Apr 1, 2013

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?

Member

hltbra commented Apr 1, 2013

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

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Apr 1, 2013

Contributor

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.

Contributor

qwcode commented Apr 1, 2013

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

This comment has been minimized.

Show comment
Hide comment
@hltbra

hltbra Apr 1, 2013

Member

I am +1 for pip-build.

Member

hltbra commented Apr 1, 2013

I am +1 for pip-build.

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

This comment has been minimized.

@hltbra

hltbra Apr 1, 2013

Member

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

@hltbra

hltbra Apr 1, 2013

Member

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

This comment has been minimized.

@qwcode

qwcode Apr 4, 2013

Contributor

yes, let me look into that.

@qwcode

qwcode Apr 4, 2013

Contributor

yes, let me look into that.

This comment has been minimized.

@qwcode

qwcode Apr 20, 2013

Contributor

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

qwcode Apr 20, 2013

Contributor

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.

This comment has been minimized.

@qwcode

qwcode Apr 20, 2013

Contributor

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.

@qwcode

qwcode Apr 20, 2013

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@hltbra

hltbra Apr 2, 2013

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.

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

Member

hltbra commented Apr 2, 2013

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

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