Re: [PATCH] tests: handle NO_PYTHON setting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johan Herland <johan@xxxxxxxxxxx> writes:

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

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


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]