Wrapping Python ?

Discussion in 'Python' started by USCode, Sep 25, 2004.

  1. USCode

    USCode Guest

    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!
    USCode, Sep 25, 2004
    #1
    1. Advertising

  2. USCode

    Peter Hansen Guest

    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
    Peter Hansen, Sep 25, 2004
    #2
    1. Advertising

  3. USCode

    USCode Guest

    "Peter Hansen" <> 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!
    USCode, Sep 25, 2004
    #3
  4. USCode

    Roger Binns Guest

    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
    Roger Binns, Sep 25, 2004
    #4
  5. In article <>,
    Roger Binns <> 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.
    Cameron Laird, Sep 26, 2004
    #5
  6. USCode

    Peter Hansen Guest

    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
    Peter Hansen, Sep 26, 2004
    #6
  7. USCode

    Roger Binns Guest

    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
    Roger Binns, Sep 26, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roy Smith

    Wrapping a C library in Python

    Roy Smith, Nov 19, 2004, in forum: Python
    Replies:
    13
    Views:
    708
    Mark Asbach
    Nov 22, 2004
  2. Andrew Wilkinson

    Wrapping C++ Class Heirachy in Python

    Andrew Wilkinson, Apr 18, 2005, in forum: Python
    Replies:
    6
    Views:
    459
    Andrew Wilkinson
    Apr 19, 2005
  3. Martin P. Hellwig
    Replies:
    3
    Views:
    483
    Martin P. Hellwig
    Jul 15, 2006
  4. Paul Anton Letnes

    Re: wrapping C functions in python

    Paul Anton Letnes, Apr 10, 2008, in forum: Python
    Replies:
    2
    Views:
    303
    Ivan Illarionov
    Apr 10, 2008
  5. L. Lindstrom
    Replies:
    14
    Views:
    818
    Gabriel Genellina
    May 2, 2008
Loading...

Share This Page