SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
> In our test suite, when 'git p4' invokes a Git command as a
> subprocesses, then it should run the 'git' binary we are testing.
> Unfortunately, this is not the case in the 'linux-clang' and
> 'linux-gcc' jobs on Travis CI, where 'git p4' runs the system
> '/usr/bin/git' instead.
>
> Travis CI's default Linux image includes 'pyenv', and all Python
> invocations that involve PATH lookup go through 'pyenv', e.g. our
> 'PYTHON_PATH=$(which python3)' sets '/opt/pyenv/shims/python3' as
> PYTHON_PATH, which in turn will invoke '/usr/bin/python3'. Alas, the
> 'pyenv' version included in this image is buggy, and prepends the
> directory containing the Python binary to PATH even if that is a
> system directory already in PATH near the end. Consequently, 'git p4'
> in those jobs ends up with its PATH starting with '/usr/bin', and then
> runs '/usr/bin/git'.
>
> So use the absolute paths '/usr/bin/python{2,3}' explicitly when
> setting PYTHON_PATH in those Linux jobs to avoid the PATH lookup and
> thus the bogus 'pyenv' from interfering with our 'git p4' tests.
> Don't bother with special-casing Travis CI: while this issue doesn't
> affect the corresponding Linux jobs on GitHub Actions, both CI systems
> use Ubuntu LTS-based images, so we can safely rely on these Python
> paths.
Good. This does not need to touch pyenv but take advantage of the
fact that we know where Python 2 and 3 are. Nice.
>
> Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx>
> ---
>
> Junio, I see that you picked up the first/RFC version and applied it
> on top of v2.26.2. This patch won't work on v2.26.2, because its 'git
> p4' is not compatible with python3 yet.
Thanks. Which means that we do not need to touch maint track (not
that we'd be merging the SHA-256 topic down to the maint track
anyway).
Will queue.
