Philip Martin wrote on Fri, Jul 24, 2015 at 14:13:04 +0100:
> Philip Martin <philip.martin_at_wandisco.com> writes:
> > Philip Martin <philip.martin_at_wandisco.com> writes:
> >> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
> >> available as a Red Hat Software Collection component.
> > The Software Collection python27 is sufficient to build Subversion and
> > run the regression tests but some of the tests FAIL. The tests that
> > fail all install a python hook script and the hook script fails to run.
> > The reason is that the Software Collection relies on setting environment
> > variables to make the Python 2.7 binary and libraries available but
> > Subversion cleans the environment before running hooks.
> If tried using a script
> LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64:$LD_LIBRARY_PATH /opt/rh/python27/root/usr/bin/python "$@"
> but it doesn't fix the FAILs as the hook scripts have an explict
> The PYTHON setting in the Makefile is the path to the script and this is
> what we want in the hook.
You could fix that by making your wrapper script set Python's argv
(at the C level) to the absolute path to the wrapper script. That'll
cause Python's sys.executable to be the wrapper script, which will make
the test harness write the path to the wrapper script in the #! line.
> We have a related, but sort of opposite, problem with parallel tests. I
> can use the script even if it is not found in PATH by doing:
> PYTHON=/path/to/script ./autogen.sh
> PYTHON=/path/to/script ./configure
> make check
> and the tests run (with the hook tests failing). If I attempt to run
> the tests in parallel
> make check PARALLEL=1
> then all the python tests SKIP because when the parallel code spawns
> additional python it uses the python found in PATH rather than the
> Makefile PYTHON.
IMO that's a bug, we shouldn't use the PATH python for subprocesses. We
should probably make the PARALLEL codepath use imp.load_module() like
Received on 2015-07-24 15:33:45 CEST