packaging for deployment

Hi all,

I'm starting to work on fixing the packaging for pydra in preparation
for a release (even if pydra is still in an alpha state).  This means
the code, and the repository, will be rearranged.  Most of it shouldn't
affect what you are working on too much (i hope). 

= packages =
The code will remain as a single repository but will include 3 separate
packages:
     1) pydra - This is the main package containing all libraries,
startup scripts, etc
     2) pydra_gui - a django app containing the front end currently
included.
     3) pydra_server - a django site  preconfigured with pydra and
pydra_gui apps.


pydra and pydra_gui will both be libraries installed to
python/site-config.  They will include scripts for easy_install
(setuptools) for easy deployment.  This allows them to be reused like
apps in the django.contrib package (admin, registration, etc).  The
intention is so that the pydra libraries are in the python path, and can
be integrated into their app closely if thats how they want to deploy it.

pydra_server is intended to be a django site that is already configured
to run.  This is something that could be deployed to any folder and run,
similar to how pydra currently works.  This is for people who do not
want to integrate pydra's interface directly into another django app.

The root of the repository will include each package.  Within the
package will be setupscripts, source directory, etc.  The source will
require setup before it can be run.  In the root folder I'll include a
master install script for installing all three packages.

= generated files =
Besides the rearrangement a few changes will happen to where generated
files are stored.  I want to conform to what a sys-admin expects a
server style app would do when its deployed

  * logs to /var/logs
  * encryption keys, ssl certs, etc moved to /var/lib
  * configuration separated from django settings and moved  to /etc/pydra
  * Startup scripts will be improved and modified to run from
/etc/init.d so that they function like any other service.

This of course will be configurable via settings file. 


questions?  comments?

- Peter

Hi all,

    The "dist" branch in the main git repo has the majority of changes
required for Pydra to be installable.  The changes were limited to
moving files and updating any file access to include file paths. 

I will merge this code sometime next week after I've had a chance to try
out all the GSOC additions. 


= How to install =
    Read the INSTALL file for more details
   

= How to setup a dev environment =
    I'll write a guide for this soon.  For my dev environment I left the
source in place and created symlinks to place the files in the correct
locations.  


= Whats Missing =
    * Proper /etc/init.d scripts - my sysadmin is helping me with this
and hopefully will get around to it this week
    * Templated installation of directories.  currently all install
paths are hardcoded in pydra/config.py this will be modified so that
platform specific directories can be used.
    * Ownership of directories is not set.
    * database configuration - this probably won't happen until we
pre-package a SQLLite database.Peter Krenesky wrote:
> Hi all,
>
> I'm starting to work on fixing the packaging for pydra in preparation
> for a release (even if pydra is still in an alpha state).  This means
> the code, and the repository, will be rearranged.  Most of it shouldn't
> affect what you are working on too much (i hope). 
>
> = packages =
> The code will remain as a single repository but will include 3 separate
> packages:
>      1) pydra - This is the main package containing all libraries,
> startup scripts, etc
>      2) pydra_gui - a django app containing the front end currently
> included.
>      3) pydra_server - a django site  preconfigured with pydra and
> pydra_gui apps.
>
>
> pydra and pydra_gui will both be libraries installed to
> python/site-config.  They will include scripts for easy_install
> (setuptools) for easy deployment.  This allows them to be reused like
> apps in the django.contrib package (admin, registration, etc).  The
> intention is so that the pydra libraries are in the python path, and can
> be integrated into their app closely if thats how they want to deploy it.
>
> pydra_server is intended to be a django site that is already configured
> to run.  This is something that could be deployed to any folder and run,
> similar to how pydra currently works.  This is for people who do not
> want to integrate pydra's interface directly into another django app.
>
> The root of the repository will include each package.  Within the
> package will be setupscripts, source directory, etc.  The source will
> require setup before it can be run.  In the root folder I'll include a
> master install script for installing all three packages.
>
> = generated files =
> Besides the rearrangement a few changes will happen to where generated
> files are stored.  I want to conform to what a sys-admin expects a
> server style app would do when its deployed
>
>   * logs to /var/logs
>   * encryption keys, ssl certs, etc moved to /var/lib
>   * configuration separated from django settings and moved  to /etc/pydra
>   * Startup scripts will be improved and modified to run from
> /etc/init.d so that they function like any other service.
>
> This of course will be configurable via settings file. 
>
>
> questions?  comments?
>
> - Peter
>
>