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
--
http://mail.python.org/mailman/listinfo/python-list
