librelist archives

development kit/distributions

From:

David Winslow

Date:

2010-05-13 @ 15:41

hey all

Yesterday in the IRC channel a few of us had a chat about the 
development kit/distribution.  Ariel in particular raised some concerns 
about having the development setup process being too complicated.  
Without going too much into options and pro/con discussions (you guys 
can provide those) here is a description of what I've been working on to 
support Ivan's work on the Haiti portal.

Running 'paver make_devkit' now produces a directory in 
share/package/devkit/ containing:
* An unmodified jetty distribution
* The WAR files for our custom GeoServer and GeoNetwork distributions
* A zipped archive of the GeoNode static resources
* A pip bundle (see http://pip.openplans.org/#bundles ) of all 
dependencies listed for the GeoNodePy project, including gsconfig.py and 
owslib packaged straight from source checkouts since we are using 
unreleased versions of both
* A copy of the pip tar.gz distribution (virtualenv magically installs 
this if it finds it in the directory being venv-ified)
* A virtualenv bootstrap script.

The bootstrap script has a custom post_install action that unpacks jetty 
and moves the wars and static resources into it so that hosting a 
geonode-based site is as simple as starting up jetty and starting a 
django site that uses the geonode django apps (and sets a bunch of paths 
properly...)

The intended workflow is that you would download 
geonode-devkit.v0.1.tar.gz, unpack it, and run "python go-geonode.py 
<some working directory>" to setup the devkit in some working 
directory.  After the devkit finishes installing you have

work/
   /bin/{activate,django-admin.py,etc}
   /lib/python2.6/...
   /share/jetty-distribution/
     /webapps/{geoserver,geonetwork,intermap}
     /webapps/static

A customized site like haiti fits into this directory structure just 
like any other python project you might work on with virtualenv, and I'd 
recommend versioning just that source tree.  So bootstrapping new 
developers on this system is a two step process - you install the 
geonode toolkit, and then you check out your site into that virtualenv.

--
David Winslow
OpenGeo - http://opengeo.org/

First of all, great work David!

The dev kit you just described (and what I have seen from your build
scripts) seem to be just what is needed to get developers up and running in
no time.

I just have a specific remark:

A customized site like haiti fits into this directory structure just
> like any other python project you might work on with virtualenv, and I'd
> recommend versioning just that source tree.  So bootstrapping new
> developers on this system is a two step process - you install the
> geonode toolkit, and then you check out your site into that virtualenv.
>

I totally agree with versioning just the source tree of your project,
however I would not recommend putting your site inside the virtualenv,
quoting James Tauber[1]:

The directory mysite-env is the environment for your project. It is
> recommended you do not edit or create new files/directories within it. The
> reason this is important is that this directory should remain reproducible
> at all times. Reproducible environments is a good idea.

 Notice the (mysite-env) bit? This is done for you by the activate script to
> help you identify which environment is currently activated. Under the hood
> your PATH has been modified to use the Python binary for this environment.


[1] http://pinaxproject.com/docs/dev/gettingstarted.html#installation

In this context it would mean something like:

work/
    geonode0.1-env/
    mysite/
            .git/
            settings.py
            damages/
                             models.py

What do you think about it?

Oh, I see.  That makes sense.  (I always forget that you can activate a 
virtualenv and have things work even in a completely separate directory.)

-d

On 05/13/2010 12:11 PM, Ariel Nunez wrote:
> First of all, great work David!
>
> The dev kit you just described (and what I have seen from your build 
> scripts) seem to be just what is needed to get developers up and 
> running in no time.
>
> I just have a specific remark:
>
>     A customized site like haiti fits into this directory structure just
>     like any other python project you might work on with virtualenv,
>     and I'd
>     recommend versioning just that source tree.  So bootstrapping new
>     developers on this system is a two step process - you install the
>     geonode toolkit, and then you check out your site into that
>     virtualenv.
>
>
> I totally agree with versioning just the source tree of your project, 
> however I would not recommend putting your site inside the virtualenv, 
> quoting James Tauber[1]:
>
>     The directory mysite-env  is the environment for your project. It
>     is recommended you do not edit or create new files/directories
>     within it. The reason this is important is that this directory
>     should remain reproducible at all times. Reproducible environments
>     is a good idea.
>
>     Notice the (mysite-env)  bit? This is done for you by the activate
>      script to help you identify which environment is currently
>     activated. Under the hood your PATH  has been modified to use the
>     Python binary for this environment.
>
> [1] http://pinaxproject.com/docs/dev/gettingstarted.html#installation
>
> In this context it would mean something like:
>
> work/
>     geonode0.1-env/
>     mysite/
>             .git/
>             settings.py
>             damages/
>                              models.py
>
> What do you think about it?