Sunday 19 June 2011

Local Lernanta Development


Back in January I blogged about getting involved in the development of the new P2PU platform - Lernanta, but time was against me. Technically speaking it still is but the desire to get involved has not gone away and now that I’m running a class there I’m spotting bits and bobs that I’d love to implement.

The folks at P2PU are keen to drink their own ‘kool aid’ and so they’ve set up a Contributing to Lernanta course for those interested in forking and adding back into the code base. The signup task is to introduce yourself and the second task is to get Lernanta installed and up and running. It was requested that we log our experience doing this and this is the context for this post.

I forked

At some point I’m hoping the work that I do will be pulled back into the master repo so I decided to fork Lernanta


I already have virtualenv and virtualenvwrapper installed so I didn’t need to do most of the steps outlined - instead I just created a virtualenv and installed the requirements. The requirements come in three files and the instructions direct users to install all three. There’s no harm in this but in requirements/dev.txt the dependancy on requirements/prod.txt is stated, so you don’t really need to install the production requirements because the dev requirements will do that for you.

The instructions state that the virtual environment be set up without using the site-packages from the global python installation. I didn’t follow this instruction because PIL and MySQLdb are an arse to install on Snow Leopard. Because of this I install them in the global site-packages python installation and let all virtualenv’s use them from there. I don’t think I’ll run into much trouble with this because the versions I’m using are stable and I’ve got no need to upgrade. ( I know that one day this will bite me )


I’m using MySQL ( with myisam tables I think) and I had a fair bit of trouble installing the migrations when setting up the database. I had to edit a number of the migration files to catch exceptions because MySQL couldn’t find a number of constraints or keys. Here’s a few examples

 # class Migration(SchemaMigration):      def forwards(self, orm):                  # Removing unique constraint on 'Link', fields ['project', 'url']         #db.delete_unique('projects_link', ['project_id', 'url'])          # Deleting model 'Link'         db.delete_table('projects_link')         ... 
 #  class Migration(SchemaMigration):      def forwards(self, orm):                  # Removing unique constraint on 'Project', fields ['name']         #db.delete_unique('projects_project', ['name'])         pass  

I know this isn’t ideal to be just commenting the things out, but it does allow the migrations to run and get me up and running.

Rabbit MQ

I have noticed that celery is in the dependancies and this has a dependancy on RabbitMQ which I don’t have installed, so I’ll be interested to see what challenges that throws up.

Looking Forward

Yesterday I finally got Vagrant up and running and I think it’d be a great idea to put a box together that we could use as a replication the development enviroment. This maybe something I’ll whip up to help me get to grips with either chef or puppet.

  class Migration(SchemaMigration):      def forwards(self, orm):                  # Deleting model 'ProjectMedia'         db.delete_table('projects_projectmedia')          # Deleting field 'Participation.sign_up'         db.delete_column('projects_participation', 'sign_up_id')          # Adding field 'Participation.organizing'         db.add_column('projects_participation', 'organizing','django.db.models.fields.BooleanField')(default=False), keep_default=False)          # Deleting field 'Project.created_by'         #db.delete_column('projects_project', 'created_by_id')         ...