Experimenting with exemaker

Didly didlybom at gmail.com
Tue Mar 8 11:36:40 CST 2011


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

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110308/92459814/attachment.htm>


More information about the Mercurial-devel mailing list