comparing alternatives to py2exe
tartley at tartley.com
Thu Nov 12 12:29:59 CET 2009
On Nov 10, 1:34 pm, Philip Semanchuk <phi... at semanchuk.com> wrote:
> On Nov 9, 2009, at 9:16 PM, Gabriel Genellina wrote:
> > En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk <phi... at 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.
> > py2exe collects in onedirectory(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 beinstalledin 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):
> >>pythonsetup.py bdist_msi
> >> The resulting MSI worked just fine in my extensive testing (read: I
> >> tried it on one machine).
> > The resulting .msi file requiresPythonalreadyinstalledon the
> > 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
> I don't thinkPython'screation process through distutils makes that
> 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,
> but we created it using only thePythonstandard library and our
> existing setup.py. Simplicity has value.
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.
More information about the Python-list