David Aguilar <dav...@gmail.com> writes:

> On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gits...@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.
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

Reply via email to