Experimenting with exemaker

[Steve Borho]

On Tue, Mar 8, 2011 at 11:46 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2011-03-08 at 09:58 -0600, Steve Borho wrote:
>> On Mon, Mar 7, 2011 at 10:39 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > I've found a neat tool:
>> >
>> > http://effbot.org/zone/exemaker.htm
>> >
>> > Given an hg.py, this program makes a 4k hg.exe that:
>> >
>> > a) finds hg.py in the same directory as it's in
>> > b) finds python.exe either in PATH or in the #! line in hg.py
>> > c) finds python.dll wherever python.exe is
>> > d) loads python.dll and launches hg.py
>> >
>> > In other words, it emulates the #! behavior of scripts on Windows.
>> >
>> > This has several advantages:
>> >
>> > - it gives you a hackable/patchable install
>> > - extensions and hooks are more easily installed
>> > - third party libraries are more easily added
>> > - hgweb becomes easier to set up
>> > - Python and hg are decoupled, so Python can be upgraded
>> > - a lot of py2exe weirdness is avoided
>> > - weirdness with command scripts calling command scripts is avoided
>>
>> It 'avoids' py2exe weirdness by performing none of the work.  How is a
>> package maintainer supposed to know which Python packages need to be
>> included?  Or which DLLs are needed by all of the Mercurial source and
>> extensions?
>
> I see this is as an upside. If you forget something (or decide it's not
> needed by enough people to warrant it), or package an old or buggy
> version, an end user can grab and install their own copy.
>
> In fact, what I'm proposing is a distribution that doesn't include ANY
> of its dependencies, including Python (the only one needed by core at
> this point).

That's what our bdist [1] packages are.  You install Python, then you
install the Mercurial bdist package, then you have a functioning
Mercurial on Windows.

[1] https://bitbucket.org/tortoisehg/thg-winbuild/downloads/mercurial-1.8.win32-py2.6.exe

>> > The first item I think is a _really big deal_ as it'll make it much
>> > easier for people to get involved in hacking Mercurial on Windows. This
>> > is pretty urgently needed as that's where we have the most users and the
>> > least developers.
>>
>> Windows is not an O/S that supports hackable programs.  If we shipped
>> source files in our installer and installed them under C:\Program
>> Files\Mercurial it would lead to a maintenance nightmare.  If any user
>> edits a .py file installed there, and they do not have write
>> privileges in that folder, from Vista on-ward the O/S will save the
>> file in a magical user-local folder and from that point onward that is
>> the copy of the file the O/S reads from if the user ever opens the
>> original file location.
>
> Hmm, first I've heard of that particular piece of byzantine insanity.
>
> Your answer suggests you think the problem isn't worth trying to solve.
> Does that mean you thing there are enough Windows developers already?

No, but adding a third installer doesn't help.

> I'm pretty sure lots of people still do real Python-based development on
> Windows, including messing with those horrible egg things, etc.. so
> presumably it IS possible to get over this hurdle.

We do for the most part.

I'll admit the bdist packages currently install an hg.bat file in the
Python26\Scripts folder, but other similar packages do install exe
files, so it should be fixable.  Not many have complained about this
because most of the bdist users are Windows users setting up Apache or
IIS to use Mercurial.

FWIW: the number of thg contributors has been steadily growing as the
Qt port has matured.  Some of them have been contributing Mercurial
patches as well, but I think Adrian is by far the hands down Windows
champion.

-- 
Steve Borho