comparing alternatives to py2exe

[Jonathan Hartley]

Hi,

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html

Columns represent methods of deploying to end-users such that they
don't have to worry about installing Python, packages or other
dependencies. 'Bundle' represents manually bundling an interpreter
with your app. 'Bootstrap' represents a fanciful idea of mine to
include an installer that downloads and installs an interpreter if
necessary. This sounds fiddly, since it would have to install side-by-
side with any existing interpreters of the wrong version, without
breaking anything. Has anyone done this?

The remaining columns represent the projects out there I could find
which would do the bundling for me.

Are there major things I'm missing or misunderstanding?

Perhaps folks on the list would care to rate (+1/-1) rows that they
find important or unimportant, or suggest additional rows that would
be important to them. Maybe an updated and complete version of this
table would help people agree on what's important, and help the
various projects to improve faster.

Best regards,

Jonathan

 

[Maxim Khitrov]

Hi,

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html

Columns represent methods of deploying to end-users such that they
don't have to worry about installing Python, packages or other
dependencies. 'Bundle' represents manually bundling an interpreter
with your app. 'Bootstrap' represents a fanciful idea of mine to
include an installer that downloads and installs an interpreter if
necessary. This sounds fiddly, since it would have to install side-by-
side with any existing interpreters of the wrong version, without
breaking anything. Has anyone done this?

Maybe there is a way to use Portable Python for this, but I have no
experience with it.

The remaining columns represent the projects out there I could find
which would do the bundling for me.

Are there major things I'm missing or misunderstanding?

Perhaps folks on the list would care to rate (+1/-1) rows that they
find important or unimportant, or suggest additional rows that would
be important to them. Maybe an updated and complete version of this
table would help people agree on what's important, and help the
various projects to improve faster.

Best regards,

 Jonathan

Good work. Recently I played with cx_freeze and compared it to py2exe,
which I've been using for a while. Here are my findings:

1. I don't think cx_freeze supports single exe. I haven't even been
able to get it to append the generated library.zip file to the
executable using documented options. Other things like .pyd files
always seem to be separate. At the same time, singe executables
generated by py2exe do not always work. I have a program that works
fine on Windows XP, Vista, and 7 if it is built under XP. However, if
I build the exact same program under Windows 7, it no longer works on
Vista or XP. I'm sure it has something to do with SxS or other dll
issues.

2. For output directory structure, you are able to specify where to
put the generated executable and all of its dependencies with both
py2exe and cx_freeze. You cannot do things like put python26.dll in a
separate directory from the executable. Not sure if that is what you
are referring to.

3. py2exe does not support Python 3 (unfortunately).

4. Although cx_freeze does support optimization (-O), it's a bit
broken in that the __debug__ variable is always set to True. In other
words, the code is optimized and things like assert statements are not
executed, but conditional statements that check __debug__ == True are.
I know that py2exe does not have this problem, no experience with
other tools.

5. py2exe is capable of generating smaller executables than cx_freeze
because of the base executable size (18.5 KB vs 1.35 MB). This is
offset by the fact that py2exe saves many more standard library
components to library.zip by default. In a quick test I just ran, both
generated a package of 4.03 MB, but I can remove at least a meg from
py2exe's library.zip. Rather than "distribution size", I think it
makes more sense to show "overhead" above the required components
(exclude minimal library.zip, python dll, and pyd files).

6. cx_freeze is as easy to use as py2exe after looking at the bundled examples.

- Max

 

[iu2]

Hi,

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output....

Columns represent methods of deploying to end-users such that they
don't have to worry about installing Python, packages or other
dependencies. 'Bundle' represents manually bundling an interpreter
with your app. 'Bootstrap' represents a fanciful idea of mine to
include an installer that downloads and installs an interpreter if
necessary. This sounds fiddly, since it would have to install side-by-
side with any existing interpreters of the wrong version, without
breaking anything. Has anyone done this?

The remaining columns represent the projects out there I could find
which would do the bundling for me.

Are there major things I'm missing or misunderstanding?

Perhaps folks on the list would care to rate (+1/-1) rows that they
find important or unimportant, or suggest additional rows that would
be important to them. Maybe an updated and complete version of this
table would help people agree on what's important, and help the
various projects to improve faster.

Best regards,

  Jonathan

Another thing that I think is of interest is whether the application
support modifying the version and description of the exe (that is, on
Windows, when you right-click on an application and choose
'properties' you view the version number and description of the
application, it is a resource inside the exe). I think py2exe supports
it.

 

[Maxim Khitrov]

Another thing that I think is of interest is whether the application
support modifying the version and description of the exe (that is, on
Windows, when you right-click on an application and choose
'properties' you view the version number and description of the
application, it is a resource inside the exe). I think py2exe supports
it.

py2exe supports this, cx_freeze doesn't.

- Max

 

[Ryan Kelly]

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html

...snip...

Are there major things I'm missing or misunderstanding?

A quick note - although I haven't tried it out, the latest version of
bbfreeze claims to support OSX.


Ryan

--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkrwyQIACgkQfI5S64uP50oDeACfUeBeF0RZYgrtorSE2n9sGnJw
9LwAoK95n8pBMDZrOxVhCFOid3ZgPbiR
=IDCJ
-----END PGP SIGNATURE-----

 

[Rüdiger Ranft]

1. I don't think cx_freeze supports single exe. I haven't even been
able to get it to append the generated library.zip file to the
executable using documented options. Other things like .pyd files
always seem to be separate. At the same time, singe executables
generated by py2exe do not always work. I have a program that works
fine on Windows XP, Vista, and 7 if it is built under XP. However, if
I build the exact same program under Windows 7, it no longer works on
Vista or XP. I'm sure it has something to do with SxS or other dll
issues.

I had similar issues with under Vista generated programs not running
under 2K (unfortunately I have to support it). This behavior came from
the .dll dependency tracking of py2exe, which included a OS .dll into
the dist output.

These are the steps I toke to find the offending .dll
* generated a "flat" directory (the .dll's not packed into library.zip)
with options = { [...], 'bundle_files': 3 }
* extracted the not loadable extension from library.zip
* examined the dependencies of this module with Microsoft's
"Dependency Walker" (you can find it somewhere in the MSDN)
* added the superfluous .dll to the
options = { [...], 'dll_excludes': ['offending.dll'] } parameter

HTH
Rudi

 

[Vesa Köppä]

Another thing that I think is of interest is whether the application
support modifying the version and description of the exe (that is, on
Windows, when you right-click on an application and choose
'properties' you view the version number and description of the
application, it is a resource inside the exe). I think py2exe supports
it.

Pyinstaller supports this.

Vesa

 

[Jonathan Hartley]

Pyinstaller supports this.

Vesa

Thanks all for the inputs. I've updated my little chart and will
continue to refine and fill in the blanks.

 

[Paul Boddie]

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output...

Nice comparison! Perhaps this could join the material on the Wiki
eventually:

http://wiki.python.org/moin/DistributionUtilities

If you don't want to spend time marking the table up, I'm sure I could
help you out.

Paul

 

[Kevin Walzer]

Hi,

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html

I noticed information on py2app was mostly missing from your chart.

--single exe file: yes, with qualification. On the Mac, standalone
applications are actually directories called "application bundles"
designed to look like a single file that can be double-clicked on. So, a
lot of stuff--the Python libraries, icons, other resource files--are
hidden inside the app bundle.

--without unzipping at runtime--Yes.
--control over output directory structure--no.

--creates installer too: yes, with qualification. If you're building an
app, you don't use an installer--the standard Mac method is
drag-and-drop installation. You can also use py2app to package up Python
libraries, and for these, it can create a standard Mac pkg installer.

--Python 3--not yet, as far as I know.
--can run as -O--not sure.
--control over process/ouput--not sure what this means.
--distribution size--Varies widely. A big Python application with lots
of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with
no other extensions would weigh in at about 20 megabytes--that's the
smallest.
--active development--some, but only in svn. Last stable release was a
few years ago.
--active mailing list--no standalone mailing list, but the PythonMac-sig
mailing list has lots of discussion and bug reporting on py2app.

 

[Jonathan Hartley]

Nice comparison! Perhaps this could join the material on the Wiki
eventually:

http://wiki.python.org/moin/DistributionUtilities

If you don't want to spend time marking the table up, I'm sure I could
help you out.

Paul

Nice idea Paul, and thanks for the offer. I'll ping you for guidance
at least, as and when I reckon I've got the table into half decent
shape. I notice the wiki page you linked to contains a bunch of
options and information I wasn't even aware of, so I've probably got
some work to do before that happens.

Best,

Jonathan

 

[Jonathan Hartley]

blank page ?

Hey Marco. Thanks for the heads-up. It's suppose to be a link to a
shared google docs spreadsheet. At least some other people are able to
see it without problems. If you're keen to see it, and it remains non-
functional for you, and you're willing to help me try and debug this,
then email me off list and maybe we could try some alternative ways of
publishing it. Do you happen to know if other google docs spreadsheets
work for you?

Best,

Jonathan

 

[Jonathan Hartley]

I noticed information on py2app was mostly missing from your chart.

--single exe file: yes, with qualification. On the Mac, standalone
applications are actually directories called "application bundles"
designed to look like a single file that can be double-clicked on. So, a
lot of stuff--the Python libraries, icons, other resource files--are
hidden inside the app bundle.

--without unzipping at runtime--Yes.
--control over output directory structure--no.

--creates installer too: yes, with qualification. If you're building an
app, you don't use an installer--the standard Mac method is
drag-and-drop installation. You can also use py2app to package up Python
libraries, and for these, it can create a standard Mac pkg installer.

--Python 3--not yet, as far as I know.
--can run as -O--not sure.
--control over process/ouput--not sure what this means.
--distribution size--Varies widely. A big Python application with lots
of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with
no other extensions would weigh in at about 20 megabytes--that's the
smallest.
--active development--some, but only in svn. Last stable release was a
few years ago.
--active mailing list--no standalone mailing list, but the PythonMac-sig
mailing list has lots of discussion and bug reporting on py2app.

Thanks heaps Kevin - I don't have a Mac, so I was just inferring
information about py2app. Although my app does run on Macs and one of
my Mac-loving friends has kindly agreed to help me produce Mac
binaries, so this information is brilliant to know. Many thanks!

Jonathan

 

[Jonathan Hartley]

I noticed information on py2app was mostly missing from your chart.

--single exe file: yes, with qualification. On the Mac, standalone
applications are actually directories called "application bundles"
designed to look like a single file that can be double-clicked on. So, a
lot of stuff--the Python libraries, icons, other resource files--are
hidden inside the app bundle.

--without unzipping at runtime--Yes.
--control over output directory structure--no.

--creates installer too: yes, with qualification. If you're building an
app, you don't use an installer--the standard Mac method is
drag-and-drop installation. You can also use py2app to package up Python
libraries, and for these, it can create a standard Mac pkg installer.

--Python 3--not yet, as far as I know.
--can run as -O--not sure.
--control over process/ouput--not sure what this means.
--distribution size--Varies widely. A big Python application with lots
of libraries can exceed 100 megabytes, easily. A Python/Tkinter app with
no other extensions would weigh in at about 20 megabytes--that's the
smallest.
--active development--some, but only in svn. Last stable release was a
few years ago.
--active mailing list--no standalone mailing list, but the PythonMac-sig
mailing list has lots of discussion and bug reporting on py2app.

Kevin,

Also:

You are right that my 'control over process/output' is not at all
clear. I shall think about what actual goal I'm trying to achieve with
this, and re-describe it in those terms.

Plus, as others have suggested, my guesstimate of 'distribution size'
would probably be more usefully described as 'size overhead', ie. how
big would the distribution be for a one-line python console 'hello
world' script. I hope to try it out and see.

Best regards,
Jonathan

 

[Philip Semanchuk]

Hi,

Recently I put together this incomplete comparison chart in an attempt
to choose between the different alternatives to py2exe:

http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html

Hi Jonathan,
I'm asking similar questions for the app suite that we're developing
on my current project, so I thank you for doing my work for me.

I was interested in py2exe because we'd like to provide a one
download, one click install experience for our Windows users. I think
a lot of people are interested in py2exe for the same reason. Well,
one thing that I came across in my travels was the fact that distutils
can create MSIs. Like py2exe, MSIs provide a one download, one click
install experience under Windows and therefore might be a replacement
for py2exe.

For me, the following command was sufficient to create an msi,
although it only worked under Windows (not under Linux or OS X):
python setup.py bdist_msi

The resulting MSI worked just fine in my extensive testing (read: I
tried it on one machine).

It seems, then, that creating an MSI is even within the reach of
someone like me who spends very little time in Windows-land, so it
might be worth a column on your chart alongside rpm/deb.

Thanks again for your work
Philip

 

[Gabriel Genellina]

En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk

I was interested in py2exe because we'd like to provide a one download,
one click install experience for our Windows users. I think a lot of
people are interested in py2exe for the same reason. Well, one thing
that I came across in my travels was the fact that distutils can create
MSIs. Like py2exe, MSIs provide a one download, one click install
experience under Windows and therefore might be a replacement for py2exe.

But py2exe and .msi are complementary, not a replacement.
py2exe collects in one directory (or even in one file in some cases) all
the pieces necesary to run your application. That is, Python itself + your
application code + all referenced libraries + other required pieces.
The resulting files must be installed in the client machine; you either
build a .msi file (a database for the Microsoft Installer) or use any
other installer (like InnoSetup, the one I like).

For me, the following command was sufficient to create an msi, although
it only worked under Windows (not under Linux or OS X):
python setup.py bdist_msi

The resulting MSI worked just fine in my extensive testing (read: I
tried it on one machine).

The resulting .msi file requires Python already installed on the target
machine, if I'm not mistaken. The whole point of py2exe is to avoid
requiring a previous Python install.

It seems, then, that creating an MSI is even within the reach of someone
like me who spends very little time in Windows-land, so it might be
worth a column on your chart alongside rpm/deb.

As said in http://wiki.python.org/moin/DistributionUtilities the easiest
way is to use py2exe + InnoSetup.

 

[Philip Semanchuk]

En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk <[email protected]

But py2exe and .msi are complementary, not a replacement.
py2exe collects in one directory (or even in one file in some cases)
all the pieces necesary to run your application. That is, Python
itself + your application code + all referenced libraries + other
required pieces.
The resulting files must be installed in the client machine; you
either build a .msi file (a database for the Microsoft Installer) or
use any other installer (like InnoSetup, the one I like).


The resulting .msi file requires Python already installed on the
target machine, if I'm not mistaken. The whole point of py2exe is to
avoid requiring a previous Python install.

You're right; the MSI I created doesn't include prerequisites. It
packaged up our app, that's it. To be fair to MSIs, they might be
capable of including prerequisites, the app, and the kitchen sink. But
I don't think Python's creation process through distutils makes that
possible.

That's why I suggested MSIs belong alongside RPM/DEB in the chart (if
they're to be included at all).

I wouldn't say that the whole point of py2exe is to bundle Python.
That's certainly a big benefit, but another benefit is that it can
bundle an app into a one-click download. That's why we were interested
in it.

As said in http://wiki.python.org/moin/DistributionUtilities the
easiest way is to use py2exe + InnoSetup.

Easiest for you. =) The list of packages and modules that might
require special treatment is almost a perfect superset of the modules
we're using in our application:
http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules

py2exe looks great, but it remains to be seen if it's the easiest way
to solve our problem. The MSI isn't nearly as nice for the end user,
but we created it using only the Python standard library and our
existing setup.py. Simplicity has value.



Cheers
Philip

 

[Jonathan Hartley]

You're right; the MSI I created doesn't include prerequisites. It  
packaged up our app, that's it. To be fair to MSIs, they might be  
capable of including prerequisites, the app, and the kitchen sink. But  
I don't thinkPython'screation process through distutils makes that  
possible.

That's why I suggested MSIs belong alongside RPM/DEB in the chart (if  
they're to be included at all).

I wouldn't say that the whole point of py2exe is to bundlePython.  
That's certainly a big benefit, but another benefit is that it can  
bundle an app into a one-click download. That's why we were interested  
in it.





Easiest for you. =) The list of packages and modules that might  
require special treatment is almost a perfect superset of the modules  
we're using in our application:http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules

py2exe looks great, but it remains to be seen if it's the easiest way  
to solve our problem. The MSI isn't nearly as nice for the end user,  
but we created it using only thePythonstandard library and our  
existing setup.py. Simplicity has value.

Cheers
Philip

Hey Philip and Gabriel,
Interesting to hear your respective perspectives - you've given me
much to ponder and to read about. Personally I'm keen to find a method
that doesn't require the end-user to have to manually install (the
correct version of) Python separately from my app, so I think that
rules out the distutils-generated MSI for me. I can see it has value
for others though.