Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 05:33 UTC
Message-ID: <BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com>
In-Reply-To: <7vsjt49stq.fsf@alter.siamese.dyndns.org>

Hide quoted text - On Wed, Apr 27, 2011 at 3:17 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Jon Seymour <jon.seymour@gmail.com> writes:
>
>>> So if you have /home/js/bin on your $PATH, you can install your "git-work"
>>> script as /home/js/bin/git-work, and that should be sufficient.
>>
>> Yep, that's a start, but does not a a complete plugin architecture make :-)
>
> Please explain yourself.
>

So, I think at a very minimum, a plugin architecture should specify the file system layout of packages to be managed by a plugin/package manager.

So, where to find scripts, where to find man pages, bash completions, configuration help etc.

A slightly more functional architecture would provide support for unpacking package archives into a "standard" repository location and for removing unwanted plugins.

A plugin architecture might specify a standard way to access extensions. (git blah is easy for local use, but what if a plugin grabs a "noun" that the core wants to use that "noun" itself in future. Perhaps gitx blah would be a better standard way to access extensions. But that is an aside, I am sure this question has been considered previously).

An even more functional architecture would provide support for a global registry of plugins. I understand that git may not want to write its own package manager (how many times has that been done), but it'd be nice if competing "git package managers" had a standard target to deploy to.

My thoughts about this are inspired by how the node project manages packages with its npm package manager and also the fact that I have several ideas on the boil at the moment that would definitely benefit from a standard way to manage these concerns.

jon.