[p2pu-dev] difficulty setting up p2pu development environment
dirk at p2pu.org
Tue Nov 13 10:12:35 UTC 2012
On Sun, Nov 11, 2012 at 5:04 AM, Asheesh Laroia <lists at asheesh.org> wrote:
> Excerpts from James Sheldon's message of Fri Nov 09 17:29:28 -0500 2012:
> > This totally worked! Thanks.
> > but then I didn't run it for a while, and the problem came back.
> > there was a new version of the virtual machine installed in the interim?
> > Incidentally, if I design a course on my local installation, will it get
> > wiped out when a new version of the software comes out?
> FWIW, I hacked around that this way in the OpenHatch Vagrant
Thanks! I think Chris did something similar to get around the problem. You
two can compare notes if you wish :)
Having said that, for the OpenHatch project, after trying Vagrant, I
> abandoned it with great enthusiasm,
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.
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.
> and just switched to bundling all
> our pure-Python dependencies in a vendor/ directory, and for the
> non-pure-Python dependencies, we use this hack:
> Now the bring-up steps are extremely simple and reliable:
> * git clone
> * python manage.py syncdb --migrate
> * python manager.py runserver
> That's all there is to it. It is an extreme relief to me, as project
> maintainer, to know it's that easy to bring up an instance of our code
> for new contributors, and I strongly encourage you folks to do the same.
> (For bundling dependencies, I use this as a baseline:
> http://fjord.readthedocs.org/en/latest/vendor.html . I see their docs
> have changed, so I should document our processes since they're slightly
> For people who need extra stuff that isn't vendor-able, we provide an
> "Advanced Installation" guide that tells them how to install the
> non-pure-Python dependencies (like PIL) on their system.
> Yes, this is awful for a sense of code cleanliness, but think of how
> great it makes things for new contributors. So that's my two cents!
Agreed, good tradeoff to make!
Thanks for your input!!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the p2pu-dev