[Distutils] Thinking about a Windows Installer

Thomas Heller thomas.heller@ion-tof.com
Tue, 23 May 2000 22:13:13 +0200


From: "Greg Ward" <gward@python.net>
To: <Distutils-SIG@python.org>
Sent: Saturday, May 20, 2000 4:41 PM
Subject: Re: [Distutils] Thinking about a Windows Installer


> On 17 May 2000, Thomas Heller said:
> > I'm currently thinking about a bdist_winexe command for distutils.
> > (Is there a better name?)
>
> How about "bdist_wininst"?
OK.

>
> > This command will create a single executable file similar to those
> > created with Wise or Installshield installers (except that you don't
> > need to have these _commercial_ programs installed).
>
> There is some sort of informal arrangement that lets Python developers
> use Wise to create installers of free Python extensions for free.  I
> think the same arrangement lets Guido create Python installers for free.
> So we probably shouldn't toss Wise out the window just because it's
> commercial; it might be a good (and zero-cost, if not entirely free)
> option for Python-on-Windows developers.

OK, will submit an 'bdist_wise' sometime. Or maybe 'bdist_wisescript'
because it will create an xxx.wse script, which has to be compiled
with Wise32.exe.

(See below for more about Wise).
>
> > This exe-File consists of a C-program embedding python, appended
> > is a zip-compatible archive of the modules to distribute, the setup.py
> > script, as well as an ini-file "setup.ini" or something like that which
> > contains the distribution meta-data in a format easily readable by
> > the C-program.
>
> Whether you want to embed Python really depends on your audience.  Let's
> face it, installing Python on Windows is not that hard.  If a programmer
> wants to use some collection of modules, it's not too bad to say,
> "Download and install Python, then download and install the module
> distribution".  Painless * 2 is not too bad.

Sure. But: Windows users are (normally) not used to the command line
(neither will they read the README file :-). They are used to installer
executables.

> For end-user applications, though, embedding a Python interpreter (and
> however much of the standard library as is needed) is probably the right
> thing to do.  I think it should be up to the module developer/packager
> to decide he distributes a "Python-less" installer or a big fat one (or
> both).

I did not think about end-user applications here. Is distutils headed in
this
direction after all?

> Now, if you *do* end up writing your own installer GUI (instead of using
> Wise), how much of it can be written in Python rather than C?  I assume
> doing this would require the presence of the Win32 extensions, so
> "painless * 2" might become "painless * 3".  Hmmm... I'd be reluctant to
> make someone install Python *and* the Win32 stuff just to run an
> installer.
> > This exe-File, when run, simply unpacks the archive into a temporary
> > directory, displays a nice GUI, runs the setup.py script, and cleans
> > up the temp-dir.
>
> I think the mode of operation should be as close to the other bdist
> commands as possible: distribute a pseudo-installation tree and just
> copy it in place.  That is, the setup script shouldn't enter into it
> here, *unless* you need it to extract package meta-data.  (Unless that's
> put into another file when you run "bdist_wininst".)

I was more thinking about a zip-selfextractor, extracting the archive into
the python installation directory automatically. The GUI is/will be
not more than a dialog box displaying some meta-info (name, version,...)
of the installed modules. The GUI is written in C.
So it is not neccessary to embed python (Maybe for compiling pyc files?)

More about Wise:
Wise is a full fledged windows installer. These programs handle the
following
and more:
- Check the access rights to install the program and its utilities
- Let the user select an installation directory
- Create shortcuts in the start menu so that the user can start the program
easily
- Care about incrementing the ref-count of shared files (usually dlls)
- Create file associations for program specific data files
- Install accessories needed for the program: database access, device
drivers, system services
- Create registry entries
- Create some meta data for uninstallation and install an uninstaller
- Care about replacing in-use files (common under windows)
Nearly all of this is not needed for python modules and extensions,
and if it is, IMO it should be handled by distutils.

The price to pay for this flexibility is that the overhead of an empty
wise script to the final installer program is about 130 kBytes (which may
be MUCH for a collection of a handfull python modules),
while a zip-selfextractor can be 20 - 30 kB.

Thomas