[PATCH] test-commandserver: use python instead of hg as the executable
Matt Mackall
mpm at selenic.com
Thu Jun 21 15:10:47 CDT 2012
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.
> And the entire testsuite passes with such a hg.cmd in lieu of the
> exemaker hg.exe.
Nice.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list