Re: RFC: a plugin architecture for git extensions?

> 2011/4/27 Motiejus Jakštys <desired.mta@gmail.com>:
> > On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote:
> > Although this looks very nice from user point of view, it would be a
> > pain for the extension maintainer... Though it's only one C file.
> >
> 
> I don't see why. You wouldn't be forced to maintain one of those
> packages, anymore than you are now. If you can, you just publish a git
> url, and your job is done.  If your tool requires compilation, you
> have already solved the distribution problem for the package managers
> you choose to support.
> 
> All I am suggesting you do is that you list pointers to these
> packages, which gpm could then use to actually do the installation for
> you.
> 
> The thing I really care about is: once the package has been installed
> locally, how do I activate it and makes its features available to the
> git runtime, without having to futz around with my PATH, MANPATH etc?
> 
> Yes, this is user focused. I want users of my tool to be able to
> something like:
> 
>    git pm install gitwork
> 
> or perhaps:
> 
>    git pm install git://github.com/jonseymour/gitwork
> 
> And then start using it. I want the git completions to be there, I
> want the man pages to be there. I want the scripts to be there. In my
> case, there I really shouldn't have to do anything other than point at
> a git url, get the package transported to a local directory and
> activate it.
> 
> I want to tell my users what they need to do to install my extension
> without having to have variants of the instructions for zip/tar
> people, apt-get people, brew people, MAC ports people, yum people etc.
> Yes, for compiled stuff, someone has to prepare the packages. But once
> they are prepared, use whatever package manager the user uses to
> install it and expose the gpm config required to activate it.

> > I think shipping it in contrib/ and having extension system is a better
> > option. Though it leaves a hole for dependencies -- if my logx depends
> > on boost or imagemagick, we don't want make git depend on it...
> >
> 
> Unless I am misunderstanding something about how contrib/ is managed
> that still requires Junio to be in the loop, which defeats one of my
> objectives here - which is to allow anyone to contribute and share
> their own extensions without being bottlenecked by someone else's
> release cycle.