Re: RFC: a plugin architecture for git extensions?

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

On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Right, my worry was based on the usual way programs find their way
>> onto my $PATH.  That is:
>>
>>  - if they are installed via a package from the distro, they are in
>>    /usr/bin.
>>
>>  - if they are installed with "make install" by the local sysadmin for
>>    all users, they are in /usr/local/bin.
>>
>>  - if I am trying them out for myself, they are in $HOME/opt/foo/bin
>>    and when it is time to remove it, "rm -fr $HOME/opt/foo".
>>
>>  - if I have adopted them, symlinks go in $HOME/bin.
>>
>> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so
>> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still
>> works without trouble.  So, barring bugs, each installation method
>> does not interfere with the other ones.
>>
>> Call it overengineering, but I would want a way for installing new git
>> commands to have the same attributes (installable by normal users in
>> multiuser systems and name conflicts not being a terrible
>> administrative burden).
>
> Ok, I wasn't thinking about folks who use repackaged /usr/bin/git together
> with their own choice of third-party enhancements.
>
> Probably we would be better off if we define a new set of paths that is
> independent from GIT_EXEC_PATH and friends.  The installed git and nothing
> else will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at
> a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user
> has her own customization, and add them to its vocabulary.
>
> Or something like that.  I am not all that interested, but it feels like a
> good direction.
>

I agree. Apologies for confusing things by talking too much about a
git pm install command.

I think there are 3 levels of functionality. FWIW, I am suggesting
git-core stops at #2.

0. unmanaged plugins

git doesn't provide any explicit management of plugins, but will use
them if finds them.

Without some kind of management, however, you will be forced to dump
the man pages and scripts
for the plugins in one place.

This would be very distribution manager unfriendly since there could
be conflicts galore.

I guess an unmanaged solution could use separate directories for each
plugin, but this would imply scanning all these paths each time you
invoke git. In my view, symbolic links from a dir already
GIT_EXEC_PATH to plugin directories would be a more efficient way to
do this.

1. managed plugins

git provides minimal plugin management functionality. Each plugin has
its own directory, but an activate step is required to make the plugin
available to the GIT_EXEC_PATH and GIT_MAN_PATH.

This has the advantage that conflicts between plugins would be more
readily avoided and is potentially more performant. As Pau suggests,
this option is much more package manager friendly

It probably does require a git plugin command of some kind, however,
in order to perform the activation step.

2. managed packages

A meta-package manager for plugins, that delegates plugin installation
concerns to a platform package manager.

The thing is, you may absolutely hate #2, but if approach #1 is
adopted by git-core, someone can at least attempt this by, well,
writing a plugin for it.

jon.