comparing alternatives to py2exe
Jonathan Hartley
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:
>
>
> 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
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
>
>
> 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
ry...@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details
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
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:
>
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
Marco Bazzani
wrote:
> 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
>
blank page ?
--
reply at:
echo "nntp at marcobazzani dot name" |sed s/\ at\ /@/ |sed s/\ dot\ /./
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.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Jonathan Hartley
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
> On Tue, 03 Nov 2009 16:58:16 +0100, Jonathan Hartley <tart...@tartley.com>
> wrote:
>
> > Hi,
>
> > Recently I put together this incomplete comparison chart in an attempt
> > to choose between the different alternatives to py2exe:
>
>
> blank page ?
>
> --
> reply at:
> echo "nntp at marcobazzani dot name" |sed s/\ at\ /@/ |sed s/\ dot\ /./
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
> On 11/3/09 10:58 AM, Jonathan Hartley wrote:
>
> > Hi,
>
> > Recently I put together this incomplete comparison chart in an attempt
> > to choose between the different alternatives to py2exe:
>
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
>
> > Hi,
>
> > Recently I put together this incomplete comparison chart in an attempt
> > to choose between the different alternatives to py2exe:
>
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
On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote:
> 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
<phi...@semanchuk.com> escribi�:
> On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote:
>>
>> to choose between the different alternatives to py2exe:
>>
>> http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output=html
>
> 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.
--
Gabriel Genellina
Philip Semanchuk
On Nov 9, 2009, at 9:16 PM, Gabriel Genellina wrote:
> En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk <phi...@semanchuk.com
> > escribió:
>> On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote:
>>>
>>> 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 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.
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.
>
>> 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.
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
> On Nov 9, 2009, at 9:16 PM, Gabriel Genellina wrote:
>
>
>
> > En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk <phi...@semanchuk.com
> > > escribió:
> >> On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote:
>
> >>> Recently I put together this incomplete comparison chart in an
> >>> attempt
> >>> to choose between the different alternatives to py2exe:
>
>
> >> 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.
> > all the pieces necesary to run your application. That is,Python
> > itself + your application code + all referenced libraries + other
> > required pieces.
> > 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):
>
> >> The resulting MSI worked just fine in my extensive testing (read: I
> >> tried it on one machine).
>
> > target machine, if I'm not mistaken. The whole point of py2exe is to
> > avoid requiring a previousPythoninstall.
>
> 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
> 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.
>
>
>
> >> 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 inhttp://wiki.python.org/moin/DistributionUtilitiesthe
> > 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,
> 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.
daniel....@gmail.com
Also, thanks for the spreadsheet, it's very useful.