Re: [PATCH 1/2] remote-helpers: tests: use python directly

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2013, 06:24 UTC
Message-ID: <7v4ndz1o8q.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAJDDKr6Qnx5ddBn=6reNOY44CxaDgD254H7M3K2mb8bbd8jpmA@mail.gmail.com>

David Aguilar <davvid@gmail.com> writes:

Show 15 quoted lines

> On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> So it is a right thing to do in that sense.
>>
>> I however am having this nagging feeling that I may be missing
>> something subtle here.  Comments from others are very much welcome.
>
> Yes, this is correct.  Another way to skin this cat would be to do
> search/replace in a Makefile to burn in the PYTHON_PATH similar to how
> we do for the .sh scripts and other .py files in the main Makefile.
> The remote helpers are in contrib/ so they do not go through the main
> Makefile, which is the root cause.
>
> Longer-term, it would be good to treat these uniformly, but this is no
> worse for now.

Ahh, so my "nagging feeling" was that remote-helpers could in theory be updated to follow the PYTHON_PATH like the rest of the system and matching these two in that direction is the better longer-term fix?

Ok, with that in mind, I still think the patch under discussion is an immediate solution that is fine as-is.

I somehow thought that there were valid reasons that we could not do so for some technical reason (e.g. the instalation of python used to run hg and/or bzr via these remote helpers and the installation of python we use may need to be different?). As long as the right longer-term direction is not "we cannot fundamentally unify them", then I am very happy.

I was worried that we might end up having to define random fine gained knobs like PYTHON_FOR_HG_PATH to allow tuning these.

Thanks for a clarification.