Junio C Hamano wrote:
> 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?
Indeed, and I already have patches for that. FTR, the Makefile does loop
through the main Makefile, which is what made implementing this so easy.
> 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 didn't think of that, and it might actually be a problem: I don't think
Mercurial works with python 3, and Bazaar probably never will.
But I don't think the current situation of always using 'python' helps either
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