Windows: COM/VB packaging

[David Bolen]

"Hung Jung Lu" <hungjunglu at hotmail.com> writes:

> In general, if I have written something that uses COM to hook up Python to 
> VB, how packageable will it be? It'll be nice if the end user only need to 
> do a few clicks to get all of Python+Win32+VB installed. It'll be too ugly 
> to ask them to install Python, Win32, and then the VB executable all 
> separately. Any advices?

I can't necessarily speak for the VB stuff, but for my own
distributions I prefer using an installer package from Gordon
McMillan:

	http://www.mcmillan-inc.com/install1.html

This automatically tracks down the various dependencies of your script
and puts it all together (along with some very nice archive formats
for the various library routines) into an executable that
self-extracts itself when it runs.  You generally end up with the exe,
a pyz for python library files a few standlone files (like
exceptions.pyc) and any external modules (dll/pyd).  That collection
of files is all you need to run your application.

The installer package has a simple installation script (console based
- prompts for a directory and unpacks), but you can combine the
installer with a Windows installation package.  That can be
InstallShield, Wise, or for my purposes, I use the free Inno Setup:

	http://www.jrsoftware.org

and you end up with your Python application looking just like a native
installed Windows application, and being totally self-contained within
its installation directory.  Users install/uninstall it just like any
other Windows application.

It's at the setup application (e.g., Inno Setup) that you should be
able to handle issues such as registration - you can automatically run
any executable during installation after your appliation has been
installed into it's directory, so if you just write support to
register yourself you're set.

Presumably you could also augment either the Python installer script
or the Inno Setup script to include whatever other VB files you might
need for the full setup.

The only potential drawback to this approach is that the installer
package defaults to making everything for the application reside in the
applications directory, so you never share even the python15.dll file
- each application has its own.  This is nice to be totally safe and
isolated but if you have several applications it can waste some disk
space.  It's really just the default behavior though.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/