Wrapping Python ?

Cameron Laird claird at lairds.us
Sun Sep 26 03:08:04 CEST 2004

In article <ol3h22-ilt.ln1 at home.rogerbinns.com>,
Roger Binns <rogerb at rogerbinns.com> wrote:
>USCode wrote:
>> subdirectory. From the Starkit website - "A Starkit creates the
>> illusion of a "file system in a file" - on the outside, it's a single
>> file, yet the application code continues to see a complete directory
>> of scripts, extensions, packages, images, and whatever other files it
>> needs."
>So what is done about shared libraries?  Python includes a number of
>shared libraries (dll/so), several of which can end up being needed, even
>by relatively simple apps.  On Windows, the Python interpretter itself
>is a shared library (python23.dll).  For a more non-trivial app such
>as my BitPim program, there are 45 libraries that end up needing to be
>packaged.  (A lot of this is because it is common practise to split
>larger packages such as wxPython and win32all into numerous independent
>py2exe and tools like that (eg cx-Freeze) do package everything into
>one file, except the shared libraries are left as seperate files,
>and user files are as well (since you have to have seperate files
>anyway for the libraries).
>The problem with shared libraries is that they have to be seperate
>files for the OS to load them properly.  One variant of the McMillan
>installer effectively extracted them at run time, but that introduces
>a whole host of problems such as the user needing write permission to
>the filesystem, security (eg a shared /tmp), and that the libraries
>may not end up being shared between processes (due to being extracted
>to different locations for security reasons).
>I tried the demo (Fractal Mountains) and can't see how it deals with
>the shared library issue.
Exactly:  taking care of shared libraries as you describe (I *think*
Starkits currently assume responsibility for writing 'em into the
real file system, and loading from there) (and, yes, I know that 
has security consequences) is one of Starkit's benefits.  Peter, it
really is neat beyond belief.

More information about the Python-list mailing list