Experimenting with exemaker

[Steve Borho]

On Tue, Mar 8, 2011 at 11:36 AM, Didly <didlybom at gmail.com> wrote:
> On Tue, Mar 8, 2011 at 4:58 PM, Steve Borho <steve at borho.org> 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?
>>
>> > 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.
>>
>> This is why we put great big disclaimers on our hgrc files telling
>> users not to edit them.  They will never (appear to) get upgraded if
>> the user writes to them.
>>
>> https://bitbucket.org/tortoisehg/stable/issue/135
>>
>> And I'm ignoring the installer rewrite this would require, because
>> that is something that is at least straightforward to resolve.
>>
>> --
>> Steve Borho
>
> Steve,
>
> I don't know if this idea is suitable for deploying mercurial to regular
> users, but perhaps it may be a great way to have a hackable distribution
> that people can use if they want to try hacking on mercurial?
>
> For example, you may recall that a while ago I had problems running
> tortoisehg from source because thg required me to have mercurial 1.8 source
> installed, but the mercurial source installer had not been released yet. I
> then asked if it was possible for me to download the mercurial repository
> and build it myself and if I recall correctly the answer was that it was not
> simple to do. Granted, I could probably learn how to do it but with the
> limited time I have every additional barrier makes it less likely that I
> will bother even trying. I guess a lot of people are in the same situation.
>
> If what Matt proposes would allow someone like me to have a source mercurial
> installation that could be easily updated to follow the mercurial repository
> it may be an improvement over the current situation...

Most of your bad experience was a result of thg developing against an
unreleased Mercurial version.  Now that 2.0 has been tagged, we will
always work against the most recent Mercurial stable release.  So
getting started on Windows should be much simpler today.

/me notes to update the Windows hackers wiki page.

-- 
Steve Borho