From: A Large Angry SCM Date: Wed, 27 Apr 2011 17:07:49 GMT Subject: Re: RFC: a plugin architecture for git extensions? Message-ID: <4DB84D65.6070906@gmail.com> In-Reply-To: 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.