From: Johan Herland Date: Mon, 30 Nov 2009 18:01:57 GMT Subject: Re: [PATCH] tests: handle NO_PYTHON setting Message-ID: <200911301901.57652.johan@herland.net> In-Reply-To: <7vvdgrordj.fsf@alter.siamese.dyndns.org> On Monday 30 November 2009, Junio C Hamano wrote: > Johan Herland writes: > > We _could_ split up the "git_remote_helpers" package into a > > "git-remote-hg"- specific package, and a "git-remote-cvs"-specific > > package, but that would mean either having two copies of the > > current support code. Alternately, we could create a _third_ > > package containing the common support code, that each of our hg/cvs > > support packages would in turn depend on. I don't think we want to > > go there, at least not yet. > > I think that is typically done by the distros; in the longer term it > would be nicer to them if we did so in our build structure, but I do > not think we are there yet. Agreed. > > Also, to prevent this misunderstanding, we could create a "python" > > subdir in git.git, and move the "git_remote_helpers" into there. > > If (and this is a big if, as we are not migrating to Python) the use > of Python proliferates over time, a single "python" subdir to hold "a > common library" to create the third package will not make sense in > the longer term, as different services written in Python will have > different set of common supporting code, so there will be multiple > common libraries and you would need multiple third packages. You > would probably need multiple directories there, perhaps as > subdirectories of that single toplevel directory you called "python", > so that scripts written in Python would say "import > pythonGit.remoteHelper" or something like that. Yes, I agree that if we get multiple Python support packages, it makes sense to create a "python" subdir, and store each package as a subsubdir of "python". Still, I don't think we need to plan that far ahead now. We can do that restructuring when it becomes necessary. If there are no more objections, I vote for keeping the current structure for now. Have fun! :) ...Johan -- Johan Herland, www.herland.net