Re: Using python + pygtk in Desktop modules (was Re: Revisiting the Gnome Bindings)

[Mike Hearn <mike navi cx>]

>   Not "my" site :)  I am unrelated to this project.

Oops, sorry! I got the wrong idea.

>    This binary compatibility note refers to the binary distribution of
> cx_Freeze itself, not programs produced by cx_Freeze.

Ah, OK. Why is cx_Freeze not distributed via itself, I wonder?
 
>   OK. The problem cx_Freeze solves is the following.  Imagine I want to
> make a 3rd party application in python.  I don't want do depend on a
> particular version of python or pygtk or whatever.  So, I install
> cx_Freeze, and I create a binary distribution of my application.  This
> binary distribution consists of a directory containing and exe file with
> statically linked python interpreter + program code, and a few shared
> libraries containing copies of all python C modules the program depends
> on.

Yes, I have seen similar things before. PAR does that for Perl on Windows.
It's inefficient but works.

>   I hear pygtk win32 developers use this trick all the time with great
> success (see for example http://wingware.com/), although they usually
> use py2exe instead of cx_Freeze (py2exe is win32 only).
> 
>   I'm not suggesting we create binary packages this way.  This approach
> produces large binary packages with much code duplication.  Normally
> it's better to just distribute the source and require a certain version
> of python and pygtk.  But for 3rd party vendors, this could be a good
> alternative.

Indeed, thanks for pointing it out.

thanks -mike