[PATCH] test-commandserver: use python instead of hg as the executable

[Adrian Buehlmann]

On 2012-06-21 00:22, Matt Mackall wrote:
> On Wed, 2012-06-20 at 23:10 +0200, Adrian Buehlmann wrote:
>> On 2012-06-20 22:26, Matt Mackall wrote:
>>> On Sun, 2012-06-17 at 11:23 +0200, Adrian Buehlmann wrote:
>>>> # HG changeset patch
>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>> # Date 1339924726 -7200
>>>> # Node ID 20c4d99cc7e96666de519418df51b6d5b7d9fad2
>>>> # Parent  a0f221f45f846aea982355840c614d6fced41edb
>>>> test-commandserver: use python instead of hg as the executable
>>>
>>> I'm not thrilled about this approach. We certainly expect "hg" to be
>>> executable, and it's simply a deferred bug of our Windows build process
>>> that it doesn't result in something called "hg" you can run.
>>>
>>> (And it's only deferred because the traditional methods of making a
>>> Python script executable on Windows all have rather large caveats.)
>>>
>>> But I don't think it's a quirk we want to enshrine in the test suite.
>>> It'd be better if we put a single gross hack in run-tests so that it
>>> just works. For instance, if no suitable hg is present, building an
>>> hg.cmd and sticking it in $TMP somewhere, then adding it to the path.
>>>
>>> ps: Wanted: benchmark comparison of startup times for .cmd, exemaker,
>>> and py2exe variants.
>>>
>>
>> If we are forced to keep (from test-commandserver.py):
>>
>> 4:    cmdline = ['hg', 'serve', '--cmdserver', 'pipe']
>> 5:    if path:
>> 6:        cmdline += ['-R', path]
>> 7:
>> 8:    server = subprocess.Popen(cmdline, stdin=subprocess.PIPE,
>> 9:                              stdout=subprocess.PIPE)
>>
>> as is, then I don't think it will be possible to use a hg.cmd.
>>
>> According to
>>
>>   http://docs.python.org/library/subprocess.html#popen-constructor
>>
>> subprocess.Popen uses CreateProcess() on Windows, which wants the name
>> of an exe ('hg' as specified on line 4 of test-commandserver.py).
> 
>> Then I see no way but providing a hg.exe (i.e. using exemaker or similar).
> 
> A quick test with shell=True seems to find my test script here:
> 
>>>> server = subprocess.Popen(['h'], shell=True, stdin=subprocess.PIPE,
> stdout=s
>>>> server.stdout.read()
> 'hello\r\n'
> 
> I think we use shell=True everywhere else in the hg code (or should) so
> things like hooks will work.
> 

Yes. If

diff --git a/tests/test-commandserver.py b/tests/test-commandserver.py
--- a/tests/test-commandserver.py
+++ b/tests/test-commandserver.py
@@ -5,7 +5,7 @@
     if path:
         cmdline += ['-R', path]

-    server = subprocess.Popen(cmdline, stdin=subprocess.PIPE,
+    server = subprocess.Popen(cmdline, shell=True, stdin=subprocess.PIPE,
                               stdout=subprocess.PIPE)

     return server

would be an acceptable change, then test-commandserver.py passes here
with a file hg.cmd in C:\Users\adi\hgrepos\hg-main containing:

  @echo off
  python C:\Users\adi\hgrepos\hg-main\hg %*

(I haven't yet figured out how to reliably specify the path to the hg
python script there - in a less hackish way).

Using such a hg.cmd file would be much simpler than having to create an exe.
Not having to provide x64 and x86 exe's would also be nice.