Going to put in a follow-up patch to remove the automatic installation of virtualenv. Per IRC convo with termie:
<jaypipes> termie: so...this bug: https://bugs.launchpad.net/nova/+bug/610402 <jaypipes> termie: that is the original one you are referring to, right? <jaypipes> termie: in regards to my patch on installing into virtualenv? <termie> jaypipes: no, not really <termie> jaypipes: so, i first added this makefile that did this stuff <termie> soren had issue with it because it was installing things on the system <termie> the decision was to move the installation to a separate script <termie> then the makefile changed to suit hudson <termie> then the makefil was removed to suit debian <jaypipes> termie: ah, ok, which was the tools/with_virt.sh and install_venv? <termie> and the test stuff put into run_test.ssh <termie> jaypipes: correcy <jaypipes> gotcha. <termie> the main goal of the whole thing is just to try to make everybody use the same environment <termie> so that bug reports are limited to actual bugs rather than library mismatches <termie> and to make it easier for people to run the tests so that they actually do it <jaypipes> termie: so, the newer bug (615906) was due to, apparently, when running install_venv, the pip -E was apparently *not* respecting the --no-site-packages... or at least, that's what it seemed to me. There should be no need to have *any* version of anyjson on my local system for run_tests.sh and install_venv.py to succeed (since pip should just install it into the venv), but that's not what happened. * jaypipes thinks that is hard to follow...but that's the story :) <termie> jaypipes: right, which is what i was guessing in my statement that it was not a clean virtualenv <termie> so i think the bugfix is to make sure it is a clean virtualenv <jaypipes> termie: but it was :) <termie> jaypipes: then fix the bug ;) <jaypipes> termie: oh, are you saying that the fix was to rm -rf the virtualenv? <termie> no, i am saying the fix is to make sure that you are getting the version of anyjson that is in the virtualenv * jaypipes really not understanding... <termie> since that is the main purpose of vitualenv and it tends to work quite well at it i am assumign somewhere in here we have some user error and my code was doing it wrong <termie> if pip is not respecting the virtualenv when it is checking dependencies we should find a way to make sure it does <termie> because it certainly seems to every time i use it <termie> otherwise it wouldn't be installing things i already have on my system <jaypipes> termie: I can only tell you what happened... <jaypipes> termie: the only solution I found was to adapt the install_venv script to call tools/with_venv.sh pip -E blah blah instead of just pip -E blah blah... <termie> jaypipes: then perhaps that is a fine solution <jaypipes> termie: which, reading the docs for pip seemed redundant, but unfortunately, that's all that worked. :( <termie> jaypipes: but the patch you have is not limited to that <jaypipes> termie: the only other thing the patch does is automatically install virtualenv instead of returning an error message saying virtualenv is required... <jaypipes> termie: when run_tests.sh is run. <termie> jaypipes: yup, but that is different functionality that, as i said, has been discussed and decided agianst previously <termie> because that was the original functionality <termie> and it was changed to be what it is now (prior to your patch) <jaypipes> termie: ok, understood now. I'll put in a follow-up to remove that part. -- pip-requires and virtualenv don't play together nicely https://bugs.launchpad.net/bugs/615906 You received this bug notification because you are a member of Registry Administrators, which is subscribed to OpenStack. _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
