Wrapping Python ?

[USCode]

Does Python have facilities for wrapping up the interpreter, any necessary
modules, GUI library, python scripts, image files, etc. up into a single
executable like exists for Tcl/Tk?
e.g. http://freewrap.sourceforge.net/
http://www.equi4.com/starkit.html

I've seen py2exe but it's not quite the same thing and doesn't appear to be
as comprehensive as the above 2 are for Tcl/Tk.

Thanks!

[Peter Hansen]

USCode wrote:

Does Python have facilities for wrapping up the interpreter, any necessary
modules, GUI library, python scripts, image files, etc. up into a single
executable like exists for Tcl/Tk?
e.g. http://freewrap.sourceforge.net/
http://www.equi4.com/starkit.html

I've seen py2exe but it's not quite the same thing and doesn't appear to be
as comprehensive as the above 2 are for Tcl/Tk.

In what way is it not the same thing? (Hint: I'm not about to
follow those links and learn about the products just to answer
the question... maybe you could explain it, since you seem to
be the one who knows about all three products.)

Also could you explain in what way you feel py2exe is not as
"comprehensive" ? It does what it does, does it well, and
doesn't really seem to be missing much in that area. Maybe
you are looking for an "installer" as well, such as InnoSetup?

-Peter

[USCode]

"Peter Hansen" <pe***@engcorp. com> wrote in

In what way is it not the same thing? (Hint: I'm not about to
follow those links and learn about the products just to answer
the question... maybe you could explain it, since you seem to
be the one who knows about all three products.)

Also could you explain in what way you feel py2exe is not as
"comprehensive" ? It does what it does, does it well, and
doesn't really seem to be missing much in that area. Maybe
you are looking for an "installer" as well, such as InnoSetup?

-Peter

I think the key difference is that they support the concept of a virtual
file system within the executable whereas, if I understand correctly, the
executable created by py2exe writes attached modules to the local disk in
specific directories before executing.

With Freewrap, it uses the Zip Virtual File System so as the attached ZIP
archive can be opened so its contents look like a simple file 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."

Also, another key difference is both the Tcl/Tk wrapping utilities are
cross-platform with both of them working on Windows and Linux. Starkit
works on OSX and lots of other platforms as well.

I'd like to generate a single executable without needing an installer or
files needing to be written out to the local disk before execution, etc.

Sorry if I'm wrong regarding the capabilities of py2exe. Otherwise perhaps
it could be enhanced someday to utilize a VFS as well.

Thanks!

[Roger Binns]

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
sub-libraries).

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.

Roger

[Cameron Laird]

In article <ol************ @home.rogerbinn s.com>,
Roger Binns <ro****@rogerbi nns.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
sub-libraries).

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.

[Peter Hansen]

Cameron Laird wrote:

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.

It may be neat, but it doesn't even seem to match the OP's own
requirements, which include this statement: "a single executable without
.... files needing to be written out to the local disk before execution"

If, on the other hand, one permits that behaviour, then I doubt
that a py2exe + UPX (or whatever that beast is called) solution
would be about the same, if not arriving with such a killer name. :-)

-Peter

[Roger Binns]

Cameron Laird wrote:

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.

In that case McMillan installer will do the same thing. There is
absolutely no way I would distribute software that extracted
libraries to bits of the filesystem every time it runs on any
platform. However others have no such qualms :-)

I did some more digging on StarKit and it looks like they build
the main executable statically linked with the most common libraries
(eg Tk). Then they require that every extension library is built
using Stubs (http://mini.net/tcl/stubs) and use a builtin mechanism
for dynamically loading the extension. That still doesn't solve
the issue for OS level linking (eg when using wxPython on Linux,
there is linkage between the wxPython library into the wxWidgets
library into GTK into X). Typically the wxPython and wxWidgets
libraries are included with the application, and it wouldn't
be feasible to use something like Stubs with the wxWidgets
library, especially since it isn't directly tied to a scripting
language and exports a huge number of functions and C++ classes.

Other than extracting libraries at runtime into the real filesystem
I can only see this to be doable by re-implementing the
operating system dynamic loader.

Roger