[Distutils] Thinking about a Windows Installer

[Greg Ward]

On 23 May 2000, Thomas Heller said:
> 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.

Great!  A bit of calibration: "bdist_rpm" exists mainly to create the
.spec file, but at the end of the job it runs "rpm -b..." for your
convenience.  It has --spec-only, --source-only, and --binary-only
options for finer control.  I think "bdist_wise" should do roughly the
same: create the .wse file, and then (optionally, but by default)
compile it with Wise32.exe.

> > 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.

No no, I'm not arguing for a command-line installer.  (Except for the
hard-code Pythonistas who want to build everything from source, and
think the current Distutils interface on Windows is just fine.)  I'm
arguing that Joe's Handy Python Modules should *just* include
joes/module1.py, joes/module2.py, and related files -- ie. pretty much
what goes into other Distutils-generated built distributions ("dumb"
tarballs or zip files, or "smart" binary RPMs).  The boundary between
Joe's Handy Python Modules and Jim's Humongous Python-Based Application
(which probably should include an embedded Python interpreter and
library) is fuzzy -- I'm not sure where eg. NumPy falls.  That should be
the developer's decision to make.

(Hmmm, now why did the name "Jim" come to mind when thinking of
humongous Python-based applications...)

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

Well, yes, eventually.  We have to keep it in mind.  Support for
"building" and installing scripts is already partly there.  (When
someone can download Zope and run "python setup.py install", and
setup.py is a reasonably normal Distutils-style setup script, then I
will hang up my keyboard and go home.)

[I outline my vision]
> 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".)

[Thomas describes his]
> 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?)

We're not contradicting each other.  By "mode of operation" I was more
concerned with how "installers" or "built distributions" or whatever are
created, and what's included in them, not how the user uses them.  Of
*course* on Windows it should be an executable -- that's the local
convention.  And if a self-extracting zip file is the best way to do it,
then do it!

A few questions/comments:

  * the default installation directory should obviously be where
    Python will find it: sys.prefix.  So you'll either have to
    run "python -c 'import sys; print sys.prefix'" or get this
    information from the registry.  I'm guessing the latter
    is preferable and doable -- as long as you can put arbitrary code
    into the self-extractor.

  * what if there are multiple Python installations -- are they
    sufficiently differentiated in the registry?  Eg. I might
    have Python 1.5.2 and 1.6a2 installed, and I would have to
    choose which one to install to.  What if it's a question of
    1.6a1 vs 1.6a2 -- are Python's registry entries sufficently
    fine-grained to resolve this?

  * should we allow writing to a different directory than the default
    (sys.prefix)?  (This would require writing a .pth file in
    sys.prefix.)  Or is this getting too close to a "real" installer?
        
  * how would the actual installer be created?  I'm hoping that
    the CCompiler abstraction would be good enough -- just create
    yourself a CCompiler (which could be a MSVCCompiler, BCCompiler,
    Mingw32CCompiler, ...) object, compile a few things, and
    link an executable.

  * interesting data point/existence proof: the Java installer-
    generator InstallAnywhere let me create an executable Windows
    installer *entirely* on my Solaris box -- I think it carries
    around a "stub" executable, and somehow generates the real
    executable by munging it with my Java code (and other stuff
    to install).  Needless to say, this is *very* cool; it is also
    an incredibly fat, slow, and heavyweight product.  If you can
    let me generate Windows installers under Solaris or Linux,
    I'll buy you *two* beers at the next Python conference.  (I
    already owe you one.)  ;-)

> 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.

Agreed, except for the somewhat mythical Jim's Humongous Python-Based
Application -- there, all of these "real installer" problems are
undoubtedly a concern.  That's not a big concern for Distutils 1.0,
though -- unless bdist_wise is really easy, I would focus on
bdist_wininst, as it sounds like it would be a lot lighter weight, and
not require any additional software other than Python/Distutils.

Wow, this sounds *neat*!  And I thought being able to build RPMs was
cool (no offense, Harry...)

        Greg
-- 
Greg Ward - Linux nerd                                  gward@python.net
http://starship.python.net/~gward/
I wonder if I ought to tell them about my PREVIOUS LIFE as a COMPLETE
STRANGER?