Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 09:59 UTC
Message-ID: <BANLkTi=UCGkQaOF7c0Ks6315gygacMzfyQ@mail.gmail.com>
In-Reply-To: <20110427093627.GH2709@jakstys.lt>

2011/4/27 Motiejus Jakštys <desired.mta@gmail.com>:

Show 38 quoted lines

> 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.