Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 5, 2011, 23:51 UTC
Message-ID: <BANLkTi=+emhzqfiGxGbnJ=bm3oL7SvjhBw@mail.gmail.com>
In-Reply-To: <7vhb986chl.fsf@alter.siamese.dyndns.org>

| Junio: apologies, reply missed list. Edited slightly.

On Fri, May 6, 2011 at 7:53 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

> David Aguilar <davvid@gmail.com> writes:
>
>> On Apr 28, 2011, at 3:56 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
>>
>>> What is so hard about the concept of an application providing a
>>> facility that allows it to request, merely request, the installation
>>> of a plugin for itself by what ever happens to be the users choice of
>>> package manager or distribution.
>>
>> It's not hard.  We simply don't need it.
>>
>> Why do I need to activate my "plugin"?  That seems like a needless
>> feature. If I don't want "git gui" I apt-get uninstall git-gui.
>
> I mostly agree with you that what Jon has wrote so far is overengineering
> to solve a problem that does not exist [*1*].
>

I do accept that the consensus of the list is that any kind of package or plugin management is over-engineering.

Show 20 quoted lines

> But here is one thought.
>
> Imagine this "git gui" is not "git gui" but "git superadd" package that
> changes the behaviour of "git add" slightly.
>
>    Side note: Of course, for this kind of usage, the "git potty" needs to
>    be extended to look for things in different places, and also it needs
>    to be made easy for the implementation of "superadd" to call the
>    underlying "git add", bypassing itself, when necessary.
>
> You do not want that new interface, you are old timer and you like the old
> way of doing things like me ;-).  But your wife wants to use it.  You two
> share a computer.
>
> Do you or do you not run "apt-get install git-superadd"?
>
> One possible answer may be to run "apt-get install git-superadd", and then
> the users who want "git add" to behave in a new way to opt-in to use the
> "plug-in".  I think that is what Jon is getting at.
>

Yes, the basic premise is that an author of a git extension, which depends only on git, should be able to provide an extension in a form that allows others to drop the extension onto a system, knowing only that the system has git installed.

The extension author should not need to know about how to build an apt-get, yum, cygwin or brew package or too much about how to install into a git installation that wasn't installed by a distro. Why should they? Their dependency is simply git.

It would be good if something like:

    unzip -d $(git --plugins-dir) foobar.zip

installed scripts, info files and man pages into a place where git would find them and then have git foobar start working without any additional effort by the package author or user.

I accept that anything more sophisticated than "drop and go" style deployment of extensions (e.g. plugin management) is overkill, given that the current market for git extensions is miniscule. That said, I would like to get the basic extension mechanism right so that if the "market" for git plugins ever became wildly successful, then at least we could implement more sophisticated plugin management if we wanted to.

This was the point of the other thread: "RFC: a minimal plugin architecture" where I tried to elicit feedback about what an minimal solution would look like, sans my more elaborate visions.

http://permalink.gmane.org/gmane.comp.version-control.git/172419

Show 5 quoted lines

>
> [Footnote]
>
> *1* I admit that I didn't read all of them carefully, as I was repelled by
> them as soon as I saw phrases like "for people who can grok this concept".

Junio: at least quote me accurately. I actually wrote:

"Contributors who grok the concept as I conceive it are welcome to submit pull requests."

I am a little mystified why use of the word "grok" in this way, given the circumstances, caused you to be "repelled".