NullSoft installer for Mercurial

Steve Borho steve at borho.org
Mon Sep 3 08:40:22 CDT 2007


<cc'ing mercurial-devel>

On Mon, 2007-09-03 at 10:13 +0200, Giovanni Bajo wrote:
> On Sun, 02 Sep 2007 23:45:30 -0500, Steve Borho <steve at borho.org> wrote:
> 
> > 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.
> 
> The first problem looks like a limit of py2exe. I don't know the details so
> I can't comment, but py2exe should allow applications to import external
> modules. What is the exact problem?

This problem may be internal to Mercurial.  I haven't looked into it
exhaustively to figure out where the break was.  I do know it's a common
complaint.

> I'm not sure what it is the second problem you refer to. Are you speaking
> of bugs that happen while developing and updated the py2exe installer? If
> this is the case, you are speaking of a development problem, not of a user
> problem caused by using py2exe (and not fixable without changing
> distribution methodology).

No, the problems I refer to have been py2exe unable to find all the modules
when the demandloading scheme was changed, and the recent problem with
patchbomb on python 2.5.  The email module was refactored in python2.5
and while there's fixup code there to allow the old naming scheme to be
used, py2exe was unable to get past the fixup code.  py2exe is just a
little bit too clever at times.

This isn't a fatal problem, but it makes it difficult to maintain.

> > 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.
> 
> (calling the two approaches InnoSoft and NSIS is a little confusing as this
> has nothing to do with the framework used to generate the installer - in
> fact, either approach could be implemented with either framework).

Agreed :)   My laptop was running out of battery power, so I didn't get
a chance to edit this paragraph.  It's the approach of the two installer
scripts rather than the tools.

> I'm a programmer, but I think I still prefer the py2exe approach, because
> it has a value: it allows Mercurial to be installed like a regural Windows
> application. It follows the standard guidelines, you find the program
> listed in the usual places, and you know how to handle it. It's the
> equivalent of using RPM/DEB for distributing it: it's the right thing to
> do.
> 
> Your approach sounds like a hybrid to me. I think the only people that
> might like it are *Mercurial* developers, which might find a quicker way to
> setup a development environment. But if I'm not interested in developing
> Mercurial, I don't see any serious advantage.

It's useful for anyone doing python development in general, especially
if you already have python installed.  The other advantage is that it
should make it easier for people to distribute/install external
extensions.  But I do see your point.

> Moreover, if the goal is to install mercurial as a Python library with all
> its dependencies, this should probably be achieved through some package
> manager (using setuptools with the correct dependency clauses). If this
> can't be done, it's the usual "Python misses a package manager", and
> nothing more.

Unfortunately, Mercurial depends on more than just python tools to have
a fully functional windows install.  I don't know of anyway to tell
setuptools to install kdiff3 or tclkit.

> -1 from me.

Ok, thanks for the feedback.  I don't think there's any chance the
py2exe approach will be deprecated.  I'm mostly interested in measuring
interest in the python based approach and get feedback on the INI file
scheme.  Does the convenience of this installer outweigh the hassle of
having two entirely different install methods?

-- 
Steve Borho <steve at borho.org>



More information about the Mercurial-devel mailing list