Subject: Re: RFC: a plugin architecture for git extensions?

From: A Large Angry SCM <[email-masked]>
Date: Wed, 27 Apr 2011 13:07:49 -0400

On 04/27/2011 12:13 PM, Jon Seymour wrote:
> I think my use of the word package was unfortunate, since it suggests
> I am proposing an alternative to tools such as apt-get, brew, rpm etc.
>
> This is not the intention. The intention is to manage _plugins_ to
> git, treating git itself as a platform.
>
> Plugins will be delivered via platform-specific package managers
> (perhaps sequenced by git-pm), but once they arrive on the OS platform
> they will be _activated_ by the plugin manager and this made available
> to the git command line.
>
> Platform specific concerns such as building and (most) dependency
> management will be delegated to platform specific package managers.
>
> The overriding objective is to allow a git user to install a git
> plugin called foobar with 4 words:
>
>       git pm install foobar
>
> given that someone, somwhere, has done the work to create a plugin
> descriptor and create an installable package of some kind for whatever
> package managers are required in order to successfully install the
> plugin on the target platform.
>
> The same command should work whether your git platform is hosted on
> MAC OSX, cygwin, Debian, Fedora, AIX or Windows.
>
> Where git can be used as the underlying package manager, it will be
> (for extensions which really are just source repos). If more
> sophisticated build support is required, then that will be delegated
> to a platform specific package manager via one of a small number of
> package manager adapters.

For a git plugin ecosystem to work, a (relatively) stable API/ABI is 
necessary for the plugin authors to code to. Where is your proposal for 
that.