deploying big python applications

[AndyL]

Hi,

let me describe how I do that today. There is standard python taken from
python.org installed in a c:\python23 with at least dozen different
additional python packages (e.g. SOAPpy, Twisted, wx, many smaller ones
etc) included. Also python23.dll moved from c:\windows to c:\python23.
This is zipped and available as over 100MB file to anyone to manually
unzip on his/her PC. This is a one time step.

On top of that there is 30K lines of code with over 100 .py files
application laid out within a directory tree. Very specific for the
domain, typical application. This again is zipped and available to
anyone as much smaller file to unzip and use. This step is per software
releases.

There is one obvious drawback - I can not separate python from standard
libraries easily. So when upgrade to 2.4 comes, I need to reinstall all
the packages. In order to address that as well as the Linux port I
project following structure:
-default python.org installation or one time step on Windows
-set of platform dependent libraries in directory A
-set of platform independent libraries in directory B
-application in directory C

This way I can easily port (or just use) entire software under
Linux/Unix yet do not have to worry about collecting all the packages
evry time I change the platform or the version of Python.

I hope I described it well enough. How to achieve it, is there any
better solution, or ready one. Please advice.

Thx in advance, A.

[Serge Orlov]

AndyL wrote:

Hi,

let me describe how I do that today. There is standard python taken from
python.org installed in a c:\python23 with at least dozen different
additional python packages (e.g. SOAPpy, Twisted, wx, many smaller ones
etc) included. Also python23.dll moved from c:\windows to c:\python23.
This is zipped and available as over 100MB file to anyone to manually
unzip on his/her PC. This is a one time step.

On top of that there is 30K lines of code with over 100 .py files
application laid out within a directory tree. Very specific for the
domain, typical application. This again is zipped and available to
anyone as much smaller file to unzip and use. This step is per software
releases.

There is one obvious drawback - I can not separate python from standard
libraries easily.
True, python releases on windows are forward incompatible with C
extensions, so don't even think about that. I'm not even talking about
big pure python packages that could probably break because of small
subtle changes in python API between releases.
So when upgrade to 2.4 comes, I need to reinstall all
the packages.
Yes, but how much time it will *actually* take? I bet it's 1 hour.
Seriously, why don't you *time* it with a stopwatch? And then compare
that time to the time needed to debug the new release.
In order to address that as well as the Linux port I
project following structure:
-default python.org installation or one time step on Windows
-set of platform dependent libraries in directory A
-set of platform independent libraries in directory B
-application in directory C

I would suggest the same structure I described for deploying over LAN:
http://groups.google.com/group/comp....7115cb6?hl=en&

The only problem is that exemaker cannot find python relative to
itself, you will have to mash exemaker, python and application launcher
in one directory. So the layout is like this:

app/
engine/ -- directory with your actual application
app.exe -- renamed exemaker.exe
app.py -- dispatching module, see below
python.exe
python24.dll
lib -- python stdlib, etc

=== app.py ===
from engine import real_application
============

This way file engine/real_application.py is platform independant.

On Linux/Unix shell script is an equivalent of exemaker. Or C program
like exemaker, but you will have to compile it for all platforms.