Re: RFC: a plugin architecture for git extensions?

[Jon Seymour <jon.seymour@gmail.com>]

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

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

> 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

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