[PyKDE] Deployment advice

[Phil Thompson]

On Friday 09 April 2004 5:16 am, Eron Lloyd wrote:
> One thing I thought of right off the bat was how SIP/PyQt are configured
> once they are built. For example, in sipconfig.py and pyqtconfig.py there
> are many hard paths, such as where to find Qt. Would it be possible to make
> relative paths instead, or set some kind of environment variable to do
> this?

The point of the config modules is to describe a setup on the installed 
system. You should not try to "share" configurations between different 
targets unless you have control over those targets and can mandate the 
directory structure. Otherwise it just gets too complicated - target 
directory structure are just too different from system to system (UNIX/Linux 
systems anyway).

> What I'm thinking is an archive similar to this:
> myarchive/
>     <install script(s)>
>     <bootstrap script>
>     ...
>     docs/
>     tests/
>     system/
>         bin/
>         include/
>         lib/
>             python/ (including PyQt & SIP built into the interpreter)
>             qt/ (the qt3.a file and whatever else is needed)
>
> Am I on the right track here? One challenge of all this is to make sure it
> can run on the latest Linux distros, such as SUSE 9 and Fedora Core 1. If I
> had to I could make it an RPM file I suppose and install everything to
> /usr/local so that the path remains the same.

You are including stuff that isn't needed by a deployed application - include/ 
and qt/ for example.

> Thanks again!
>
> Eron
>
> On Thursday 08 April 2004 10:09 pm, Eron Lloyd wrote:
> > Hi all,
> >
> > I'd like to build a pretty much self-contained package to deploy my
> > PyQt-based system. The reason being is that we need to have our system
> > tested by as many people as possible to ensure it is working correctly.
> > To do that, I've done some research into possible alternatives, and came
> > across Phil's helpful document on deployment about a year ago. I've
> > noticed that the solution Phil covers is Gorden McMillan's Installer
> > package, which has been discontinued as far as I can tell.

I hope this is temporary.

> > However, there are some interesting concepts in the document that could
> > still be utilized. Specifically, I'd like to see if it is possible to
> > create an archive that includes the code for my project, a full Python
> > binary package with PyQt and SIP built into the interpreter, and a static
> > Qt library. I'm just now beginning to investigate this approach, and am
> > willing to document and share my findings with the community.

Why ship a static Qt library?

> > I'd like to try this approach instead of the "single binary" solution
> > such as freeze and py2exe, as once the package is installed, I'd like to
> > experiment with providing module updates over the network and dynamically
> > loading new code.
> >
> > If this is an insane idea please let me know, and perhaps suggest some
> > different approaches. I'd *really* like to continue using PyQt/Python for
> > this project instead of moving to Qt/C++, so any help would be GREATLY
> > appreciated.

Obviously you can't provide separate module updates if they are builtins.

I don't see what difference C++ vs Python makes to this problem.

Personally I'd look to using an existing packaging system for the initial 
deployment - and maybe also for network updates (but perhaps triggered 
automatically by the application).

What you deploy depends on the nature of your users. Do you have control over 
their environment - or do they hack with their own systems? How dependent is 
your application on particular version numbers? For an application that you 
want people to use easily but not pester you with support calls, I would tend 
to go the route of building your own Python interpreter with all the modules 
you use (but are unlikely to change yourself) as builtins. Create it with 
minimal dependencies on external libraries (eg. glibc and X11 only), and 
install it in it's own directory hierachy, perhaps with a single script 
in /usr/bin. You can then go to town (or not) on providing automatic network 
updates.

Phil