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

[Adrian Buehlmann]

On 2012-06-21 22:10, Matt Mackall wrote:
> On Thu, 2012-06-21 at 02:06 +0200, Adrian Buehlmann wrote:
>> On 2012-06-21 00:42, Adrian Buehlmann wrote:
>>> 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).
>>
>> This one works (partly stolen from contrib/win32/hg.bat):
>>
>>   @echo off
>>   python "%~dp0hg" %*
> 
> Yeah, something like that will usually work. Unfortunately, the "%~dp0"
> magic is not terribly reliable:
> 
> http://stackoverflow.com/a/7689467/975761
> 
> It really depends on the precise details of how the calling process sets
> up the subprocess environment.
> 
> Also note that since "@" means "don't echo this command", this can be a
> one-liner.
> 

Thanks for that warning and the tip.

So we either find a correct hg.cmd, or I have to resort to using hg.exe
again. Hmmm.