Re: RFC: a plugin architecture for git extensions?

[Jon Seymour <jon.seymour@gmail.com>]

2011/4/27 Motiejus Jakštys <desired.mta@gmail.com>:
> On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote:
>> On Wed, Apr 27, 2011 at 6:15 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> > On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber
>> > <git@drmicha.warpmail.net> wrote:
>> >
>> The idea would be to maintain a registry of "git package descriptors".
>> The descriptors would be a copy of the whatever descriptor an
>> activated package would be described by, but probably simply a git
>> config text file, since we already have the tools to parse those.
>>
>> Such a descriptor would have hints about how to use a real package
>> manager to get the actual package, but would not actually contain any
>> files from the package itself.
>
>>
>> So, for example, the package source might be bundled in git-core
>> contrib/ directory, fetchable as a git repo, fetchable as a tar ball,
>> fetchable as an apt-get package, as brew package etc. The idea is that
>> gpm would know enough about invoking a real package manager to handle
>> the actual distribution details.
>
> Let me check If I get this right:
> Say I am a maintainer of enchanced git log -- git logx. It is one .c
> file, which has to be simply compiled (cc -o git-logx logx.c).
>
> If I want to maintain the package in a way you are suggesting, I have to
> prepare deb, rpm, tarball, zipball, brew (what ever it is, sorry for
> non-intelligence) and what not. Otherwise, I lose users? *ball is not
> an option, since we are supporting different architectures and cannot
> distribute compiled files (unless statically compiled for all
> architectures we know, which is not good for obvious reasons).
>
> Morevoer, different debs for different debian releases (if package
> depends on libc version)?
>
> 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.

jon.