Re: RFC: a plugin architecture for git extensions?
- From
A Large Angry SCM <gitzilla@gmail.com>
- Date
- Apr 27, 2011, 17:07 UTC
- Message-ID
- <4DB84D65.6070906@gmail.com>
- In-Reply-To
- <BANLkTikGZgEb-4jzHt+t2k__s7BMgbU9gg@mail.gmail.com>
On 04/27/2011 12:13 PM, Jon Seymour wrote:
Show 32 quoted lines
> 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.