I'd like to reopen discussion on the Windows path problem

[Lee Cantey]

The issue was discussed quite a bit over a year ago
(http://www.selenic.com/pipermail/mercurial/2005-July/001760.html) but
there was never a final resolution.

The problem usually occurs when Mercurial needs to talk to one of the
dynamic libraries.  Under Unix-like operating systems they are built
in the 'mercurial' subdirectory (with make local for instance) but
under Windows they show up in 'build'.

The proposal was to test if the user wasn't running hg from the
current directory then move the cwd (if present) to the end of the
python load path.  I'm not sure that moving it to the end rather than
removing it actually has a real purpose though.

I used the following patch based on the earlier one for the latest
Windows binary since you'll never want the current directory in that
case and it allows running from the hg directory to work.  I'd propose
removing the appending unless I've missed the reason for it.

diff -r 27230c29bfec hg
--- a/hg	Sun Dec 17 05:00:22 2006 +0100
+++ b/hg	Fri Dec 22 09:56:48 2006 -0800
@@ -7,6 +7,17 @@
 # This software may be used and distributed according to the terms
 # of the GNU General Public License, incorporated herein by reference.

+import os, sys
+
+cwd = os.getcwd()
+if cwd in sys.path:
+    # Always remove current directory for Windows exe
+    if hasattr(sys, 'frozen'):
+        sys.path.remove(cwd)
+    elif os.path.dirname(__file__) != cwd:
+        sys.path.remove(cwd)
+        sys.path.append(cwd)
+
 from mercurial import commands

 commands.run()