Re: [PATCH] tests: handle NO_PYTHON setting

> 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.

> > 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.