Re: [PATCH] tests: handle NO_PYTHON setting

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2009, 08:49 UTC
Message-ID: <7vr5rgv1lr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <fabb9a1e0911300035o532153b7qdc2ecd768200ce09@mail.gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> writes:

Show 14 quoted lines

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