Re: Test failures with python versions when building git 1.8.1

From: Jeff King <peff@peff.net>
Date: Jan 2, 2013, 06:53 UTC
Message-ID: <20130102065345.GA8685@sigill.intra.peff.net>
In-Reply-To: <7va9ss5fhq.fsf@alter.siamese.dyndns.org>

On Tue, Jan 01, 2013 at 09:19:13PM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Dan McGee <dan@archlinux.org> writes:
> 
> > A test case snuck in this release that assumes /usr/bin/python is
> > python2 and causes test failures. Unlike all other tests and code
> > depending on python, this one does not respect PYTHON_PATH, which we
> > explicitly set when building git on Arch Linux due to python2 vs
> > python3 differences.
> 
> I had an impression that you are not supposed to run our scripts
> with python3 yet (no python scripts have been checked for python3
> compatibility), even though some people have expressed interests in
> doing so.
> 
> Eric?

Yeah, but the worrying thing to me is that we are not respecting PYTHON_PATH. So even if Arch does everything right, it is getting punished just for having python3 on the system at all.

I think we need to either:

  1. Build contrib/svn-fe/svnrdump_sim.py into svnrdump using our normal
     build procedure, which handles $PYTHON_PATH (right now we seem to
     just symlink[1] it into place as svnrdump during the test script
     run).

  2. Create svnrdump as a shell script in the test suite to do something
     like[2]:

       $PYTHON_PATH "$TEST_DIRECTORY"/../contrib/svn-fe/svnrdump_sim.py

-Peff

[1] This symlink is doubly wrong, because any use of symbolic links
    in the test scripts needs to depend on the SYMLINKS prereq, and this
    does not.

[2] In both the current code and what I showed above, the test scripts
    depend on things in contrib/. This is probably a bad idea in
    general, as the quality of what goes into contrib is not as closely
    watched (especially with respect to things like portability).
    Certainly I would not have known to look more carefully at a patch
    to contrib/svn-fe for breakage to the test suite.

    FWIW, we also have this situation with t9902 (bash completion),
    though the dependency is a little more obvious there. It might be
    worth promoting bash completion out of contrib (or alternatively,
    demoting t9902 into contrib/completion/, possibly with a feature to
    make it easier to run tests out of contrib).