Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Wrapping Python ?

Reply
Thread Tools

Wrapping Python ?

 
 
USCode
Guest
Posts: n/a
 
      09-25-2004
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!


 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      09-25-2004
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
 
Reply With Quote
 
 
 
 
USCode
Guest
Posts: n/a
 
      09-25-2004
"Peter Hansen" <(E-Mail Removed)> 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!


 
Reply With Quote
 
Roger Binns
Guest
Posts: n/a
 
      09-25-2004
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



 
Reply With Quote
 
Cameron Laird
Guest
Posts: n/a
 
      09-26-2004
In article <(E-Mail Removed)>,
Roger Binns <(E-Mail Removed)> 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.

.
.
.
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.
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      09-26-2004
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
 
Reply With Quote
 
Roger Binns
Guest
Posts: n/a
 
      09-26-2004
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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python 2.6 and wrapping C libraries on Windows L. Lindstrom Python 14 05-02-2008 04:35 PM
Re: wrapping C functions in python Paul Anton Letnes Python 2 04-10-2008 04:30 PM
ctypes wrapping libpam.so on FreeBSD 6.1 - Python Bus Error Martin P. Hellwig Python 3 07-15-2006 12:58 PM
Wrapping C++ Class Heirachy in Python Andrew Wilkinson Python 6 04-19-2005 11:47 AM
Wrapping a C library in Python Roy Smith Python 13 11-22-2004 11:25 PM



Advertisments