Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 21:47 UTC
Message-ID: <BANLkTi=H3oU5SxwJJZ9ZYJBWy+VS2CvJ7w@mail.gmail.com>
In-Reply-To: <20110427212943.GA2646@jakstys.lt>

2011/4/28 Motiejus Jakštys <desired.mta@gmail.com>:
- Hide quoted text -

Show 39 quoted lines

> On Wed, Apr 27, 2011 at 01:36:44PM +1000, Jon Seymour wrote:
>> Has anyone ever given consideration to git supporting a plugin
>> architecture for git extensions?
>>
>
> How about this proposition? From the user perspective:
> $ cd /somewhere/might/be/home/or/project/.git/ext/
> $ git clone git://github.com/jonseymour/gitwork.git
>
> What user finds in gitwork/ is totally up to maintainer. git cares about
> two files:
>    .git/ext/git-work(.exe)
>    .git/ext/git-work.1.gz
>
> $ cd gitwork;
> $ (c)make|./waf|scons|what_the_hell_just_produce_git-work
> $ git config ext.work.enabled true
>
> What git does when git <command> is invoked:
> -------------------------------------------
> * config.ext.<command>.enabled is true. If not, do nothing new.
> * if above is true, search for git-work in:
>  ** project directory
>  ** user home directory
> * if found, execute it
> * if not found, fallback to default mechanism (check in
>    cmd_struct_commands, etc)
>
> Similar with man pages.
>
> Think about how Vim plugins are distributed. Vim developers assumed that
> users are educated enough to download the plugin and extract it to the
> right place. Are git users less intelligent to download & install it,
> especially in a case when they need an *extension*?
>
> Are you trying to kill a bird with a rock?
>
> Motiejus
>

I think that is a little more invasive of git-core than it needs to be.

I was thinking more along the lines of, having solved the distribution and build problem _some other way_, resulting in a foobar.gpm file ending up in, say, /usr/local/lib/git-pm/foobar.gpm.

You would then run:

   git pm activate foobar

which would then link:

  ln -sf /usr/local/bin/git-foobar ~/.git-pm/activated/libexec/git-foobar
  ln -sf /usr/local/share/man/man1 ~/.git-pm/activated/share/man/man1

One would have to have previously arranged for the sub directories of ~/git-pm/activated to be in the PATH and MANPATH paths.

Deactivating would involve removing the links.

Deciding which links to link during activation and de-activation would be driven by a short descriptor file.

jon.