Re: [PATCH] tests: handle NO_PYTHON setting

[Johan Herland <johan@herland.net>]

On Monday 30 November 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> 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, <johan@herland.net>
www.herland.net