Re: RFC: a plugin architecture for git extensions?

[Michael J Gruber <git@drmicha.warpmail.net>]

Jon Seymour venit, vidit, dixit 27.04.2011 09:15:
> On Wed, Apr 27, 2011 at 3:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jon Seymour <jon.seymour@gmail.com> writes:
>>
>>> 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.
>>
>> Sounds like you have a plan ;-)
>>
> 
> Ok, here we go:
> 
>     https://github.com/jonseymour/gpm
> 
> Anyone who violently objects to the suggested name of a package
> manager interface - gpm, please speak up now because it'll be easier
> to change now.
> 
> (And yes, gpm is intended to be an *interface*. The idea would be to
> allow the interface to be back-ended by different implementations
> depending on taste, platform etc.).
> 
> I suggest using this list for discussion, but I also think the github
> issue manager would be a pretty good option.
> 
> Speak up if, you see anything wrong so far!

I'm sorry to spoil the party before it started but I'm not very fond of
having yet another package manager orthogonal to what distributions have
already. This is definitely not a way to get anything like that into a
distribution which has proper policies.

What we could need now to help users is a working "make -C contrib/foo"
to easily install selected features from our contrib area (with
"install" or "doc" targets), i.e. set things up so that we can have very
simple makefiles in contrib (with an include).

If you really want to go forward with a bigger solution, we could
distribute "extensions" by installing but not "activating" them, and
have some command which activates them selectively (like hg extensions).
That is something distributions could ship, although I don't see any
need for it personally. Our architecture makes it so easy to "integrate"
git-foo, git-foo.1 and config variables without touching the core git
installation at all!

Michael