Re: [PATCH] tests: handle NO_PYTHON setting

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2009, 17:27 UTC
Message-ID: <7vvdgrordj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200911301159.23383.johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 5 quoted lines

> ... Hence, this subdir is 
> meant to contain the support scripts for remote helper written in Python, 
> both common support scripts, and support scripts specific to each remote 
> helper. So far, only the common code is there, but we expect the Hg and CVS 
> helpers to add scripts to the "hg" and "cvs" subsubdirs, respectively.

Ahh, Ok, that clarifies it. The packager (not me) can package what is (in|built from) remote_helpers directory into one package, and declare that as a dependency to each of the individual remote helper packages that uses the common stuff found in there, if the distro wants to have "one end-user feature per package" granularity.

Just to make sure you didn't misunderstand me, I wasn't complaining that the directory was not further split for each helper. I wanted to know the reason behind wanting to have _one_ directory that is common across multiple helpers that are supposed to be independent. "A common library" is a good reason to have that organization.

Show 6 quoted lines

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