NullSoft installer for Mercurial

[Patrick Mézard]

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

To summarize, I would rather have both extreme solutions made even 
easier than trying the hybrid one.

Anyway, thank you for all the time you are throwing in these 
deployment/packaging issues, this is valuable to make the whole thing 
smoother under Windows. Even if I would not support an official build of 
your hybrid solution myself, I would be happy to make things easier for 
you to support one and help people experimenting with it.

--
Patrick Mézard