comparing alternatives to py2exe

[Jonathan Hartley]

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:
>
> >>>http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdg&output...
>
> >> 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  
> 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,  
> 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.