NullSoft installer for Mercurial
pmezard at gmail.com
Wed Sep 5 15:37:04 CDT 2007
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.
More information about the Mercurial-devel