David Aguilar <davvid@xxxxxxxxx> writes: > On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html