NullSoft installer for Mercurial

[Steve Borho]

On Wed, 2007-09-05 at 22:37 +0200, Patrick Mézard wrote:
> Steve Borho a écrit :
> > 
> > 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.
> 
> I probably feel like Giovanni Bajo about this, there are two groups of 
> users and this hybrid solution may not satisfy any of them.
> 
> 1- The python fluent ones, who can build the package via setup.py and 
> configure everything in a couple of minutes. The last thing they want is 
> something editing stuff in their existing python environment with much 
> less control than a regular package. Sure they will get the contrib 
> tools for free, but I expect most of them to already have a merge tool, 
> and setting up tcl/tk is really easy.
> 
> 2- The pure users. They want Mercurial and whatever bonus they can get 
> with it. They do not care about python. *They are likely to install a 
> package version provided by their organization*, which means deployment 
> ease (and therefore components isolation) is important. At worse, if 
> they really need some feature they could ask someone to generate a new 
> package including it, and deploy it again. Your "batteries included" 
> perfectly fit the bill.
> 
> The hybrid solution you propose is tempting but in the end I am not sure 
> this is what I am looking for. We are currently three developers working 
> with Mercurial (mostly Mercurial over SVN), one under Linux, another and 
> me under Windows. The other Windows developer don't have the tools nor 
> the skills to build it and install it painlessly. I currently give him 
> distutils build directories from slightly hacked crew versions, which he 
> moves in site-packages manually. Clearly, when I have time, I will take 
> a look at Lee Cantey build instructions or yours and find a way to 
> generate my own private builds, so he can setup a new one with a single 
> click. An somehow, it looks like you hybrid installer: he has python and 
> setup prebuild packages. But the interesting feature is or would be to 
> upgrade easily by just replacing the previous version by a new one, 
> which I think the all-in-one installer can achieve, rather than having a 
> collection of components neatly combined (for how long ? this is Windows 
> :-)).

Great points.  

I think the "python" approach lends itself to upgrading components much
more than the all-in-one installer does.  After the initial install you
can upgrade mercurial by installing a new MSI/egg or even building it
yourself.  There's no need to download another big package (and risk
destroying your configuration).

Both approaches have their complexities and their drawbacks, and I don't
think either of them will ever "win".  It all depends on how you intend
to use it after it's installed.

Now that I've gone down both routes, if I was going to deploy Mercurial
across a company I would probably chose the NSIS install tool, simply
because it is much more capable at doing upgrades (only downloading and
installing pieces that it determines you need) and post-install tuning,
regardless of which bundling approach I chose.

My next task is to make a web page, or possibly a wiki page, detailing
the two approaches along with their drawbacks and advantages.

PS: Gmail is rejecting all my mail these days, so don't be surprised to
not get a direct reply.

PS2: I'm still waiting for more feedback on the "batteries included"
installer.  If anyone is actually using it :) , please let me know where
it needs to be improved.

-- 
Steve Borho <steve at borho.org>