NullSoft installer for Mercurial

[Steve Borho]

(sorry about the length of this e-mail)

After some prodding (and very useful example scripts) from Brad Schick,
I've built a prototype mercurial windows installer using NSIS.  You can
get to the installer repository from http://hg.borho.org/hg-nsi
and the NSIS compiler from here: http://nsis.sourceforge.net/Main_Page

This installer works very differently than the Inno Setup installer,
which used py2exe to bundle together mercurial, the python DLL, and all
required python modules and packages into an opaque library.zip file and
some framework, and then install the whole package under C:\Program
Files\Mercurial.  This closely follows the "Windows" approach of program
installation, and basically tries to minimize the fact that Mercurial is
a python application (for better or worse).  There are many drawbacks to
the py2exe scheme, the two worst of which are the difficulty in adding
extensions and the various problems you run into when it doesn't pull in
all the modules you actually need.

My "Batteries Included" installer compounds this issue by cramming even
more things into the single installer.

The NSIS installer comes at this from an entirely different perspective.
It installs Mercurial as a python app that tries to minimize the fact
it's running on Windows.  The actual EXE file contains no data.  It
merely scans your computer and identifies all the tools you need to run
Mercurial natively.  It will download and install (on demand) python
2.5, pywin32 extensions, setuptools, and then the mercurial MSI file.
The first page allows you to specify whether you want a commit tool
(qct), history viewer (tclkit/hgk), and merge tool (kdiff3).  If you
select those options, it downloads and installs PyQt4, tclkit, kdiff3,
then the qct MSI file.

An MSI file is essentially a python egg file with a built in
installer/uninstaller.  When you use setuptools in place of the standard
python distutils, your setup.py script can generate these MSI files with
little modification.  I've comitted the setup-msi.py file I used to
create the mercurial MSI file, in case your curious (note: the bdist_msi
target requires N.N.N revision numbers, so the MSI I built says it's
0.9.4, but it's actually mainline tip).

What the mercurial MSI installer places on the windows machine is
basically the equivelent of what they would have received if the user
built and installed it themselves.  The mercurial/ and hgext/ packages
are stored under C:\Python25\lib\site-packages, and the C extension
modules are pre-built.  Templates/ and contrib/ are stored in C:
\Python25\Mercurial

The benefits of this layout are many.  The user has a fully-fledged
python development environment.  Kdiff3 is fully installed (available
via context menus, etc).  It is extremely easy to add or upgrade
extensions.  And lastly it's very simple (and efficient) to upgrade
mercurial itself, since they only need to download and install the
latest MSI file (which is ~0.5MB).

I'm thinking that there will be many people who like the Inno Soft
approach (in a nutshell, non-programmers), and many people who will like
the NSIS approach.  I have no idea how to bring the two together.

The big gaping hole in the NSIS installer (I did call it a prototype,
remember?) is that it does not generate any Mercurial.ini file, or any
of the various shell scripts (hgmerge.cmd, hgk.cmd, etc).  NSIS has
excellent capabilities for doing INI file management and file
manipulations, but I'm unsure about the best approach.

There's three possibilities:

1)  I create a single Mercurial.ini that assumes the full installer was
run, get the username from the user at install time and add it to the
file.

2)  Add support in Mercurial for C:\Python25\Mercurial\hgrc.d and allow
apps to add files there, just like /etc/mercurial/hgrc.d on unix.

3)  I fake option #2 by make a post-install script that pieces together
all the files it finds there.. then each package that adds hgrc files is
responsible for running the script.

I would pick #2, because it kinds of follows from the work Jonathan
Shapiro is doing making our directory layout more flexible.  Optimally,
the NSIS installer would create the hgrc.d directory and a master
Mercurial.ini.  Inside the master file it would declare where hgrc.d/
was and where external extensions should be installed.  It would also
put those in the registry so that other installers could find them.

I cross-posted to the non-dev list because I suspect many Windows users
do not subscribe to the dev list, and I'd like broad feedback on this.

Cheers,

-- 
Steve Borho <steve at borho.org>