Re: [PATCH] tests: handle NO_PYTHON setting

[Junio C Hamano <gitster@pobox.com>]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> On Mon, Nov 30, 2009 at 09:28, Junio C Hamano <gitster@pobox.com> wrote:
>> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>> I don't think that's true, git.git currently does not have such a
>>> structure (everything is just dumped in the root directory). The only
>>> reason git_remote_helpers exists is to make it easier to create a
>>> python egg out of it and install that.
>>
>> If that is the case, shouldn't each of the helper written in Python need
>> to have a separate directory, not just a single git_remote_helpers
>> directory shared among them?
>
> I don't understand why that would be needed? The reason we added a
> single git_remote_helpers directory is because we wanted to share
> common code, having a single python package makes that easy.

Sorry, I don't understand that.  With that reasoning, isn't having a
single git package, be it python or not, even easier?  Why would anybody
want a separate egg that includes everything that _happen_ to be written
in Python in the first place?  It doesn't make sense at all from packaging
point of view to me.

A separate egg per remote-helper that you can pick and choose which ones
to install and which ones to leave out would make perfect sense, exactly
the same way that distros already split git into "git-core", "git-svn",
etc., though.  Your "git-hg" may consist of a single egg and perhaps some
other supporting code, and people who want to convert away from legacy Hg
repository may want to install it, but it is entirely up to them if they
also want to install "git-cvs" that is implemented as a remote-helper that
happens to be written in Python, no?