On Tue, Jan 01, 2013 at 09:19:13PM -0800, Junio C Hamano wrote:
> Dan McGee <d...@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.
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 it into place as svnrdump during the test script
2. Create svnrdump as a shell script in the test suite to do something
 This symlink is doubly wrong, because any use of symbolic links
in the test scripts needs to depend on the SYMLINKS prereq, and this
 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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html