Hi Asheesh<br><br><div class="gmail_quote">On Sun, Nov 11, 2012 at 5:04 AM, Asheesh Laroia <span dir="ltr"><<a href="mailto:lists@asheesh.org" target="_blank">lists@asheesh.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from James Sheldon's message of Fri Nov 09 17:29:28 -0500 2012:<br>
<div class="im">> This totally worked!  Thanks.<br>
><br>
> but then I didn't run it for a while, and the problem came back.   Perhaps<br>
> there was a new version of the virtual machine installed in the interim?<br>
><br>
> Incidentally, if I design a course on my local installation, will it get<br>
> wiped out when a new version of the software comes out?<br>
<br>
</div>FWIW, I hacked around that this way in the OpenHatch Vagrant<br>
configuration:<br></blockquote><div> <br>Thanks! I think Chris did something similar to get around the problem. You two can compare notes if you wish :)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Having said that, for the OpenHatch project, after trying Vagrant, I<br>
abandoned it with great enthusiasm,</blockquote><div><br>Can you please elaborate on why you abandoned Vagrant? I'm not using Vagrant myself and some of our community members mentioned that old hardware stops them from running a virtual machine for development/testing.<br>
<br>One thing that is sticking in the back of my mind is that we are moving towards using more HTTP API's in the backend that doesn't play well with 'manage.py runserver'. Up until now I've been using a custom VM to test this, but it should be fairly simple to have a Vagrant VM for that.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and just switched to bundling all<br>
our pure-Python dependencies in a vendor/ directory, and for the<br>
non-pure-Python dependencies, we use this hack:<br>
<br>
<a href="https://github.com/openhatch/oh-mainline/blob/master/mysite/base/depends.py" target="_blank">https://github.com/openhatch/oh-mainline/blob/master/mysite/base/depends.py</a><br>
<br>
Now the bring-up steps are extremely simple and reliable:<br>
<br>
* git clone<br>
<br>
* python manage.py syncdb --migrate<br>
<br>
* python manager.py runserver<br>
<br>
That's all there is to it. It is an extreme relief to me, as project<br>
maintainer, to know it's that easy to bring up an instance of our code<br>
for new contributors, and I strongly encourage you folks to do the same.<br>
<br>
(For bundling dependencies, I use this as a baseline:<br>
<a href="http://fjord.readthedocs.org/en/latest/vendor.html" target="_blank">http://fjord.readthedocs.org/en/latest/vendor.html</a> . I see their docs<br>
have changed, so I should document our processes since they're slightly<br>
different.)<br>
<br>
For people who need extra stuff that isn't vendor-able, we provide an<br>
"Advanced Installation" guide that tells them how to install the<br>
non-pure-Python dependencies (like PIL) on their system.<br>
<br>
Yes, this is awful for a sense of code cleanliness, but think of how<br>
great it makes things for new contributors. So that's my two cents!<br></blockquote><div> <br>Agreed, good tradeoff to make!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">
-- Asheesh.<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>Thanks for your input!!<br><br>Cheers<br>d <br></div></div><br>