Re: RFC: a plugin architecture for git extensions?

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

On Thu, Apr 28, 2011 at 10:55 AM,  <david@lang.hm> wrote:
> On Thu, 28 Apr 2011, Jon Seymour wrote:
>
>> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano <gitster@pobox.com>
>> wrote:
>>>
>>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>>
>>
>> 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.
>
> every package manager I know of has no problem with multiple packages owning
> files in one directory.
>
> if the files are named the same thing you will have a conflict, but if the
> files are named the same thing, the commands are probably going to be named
> the same, and so you will have conflicts in any case.
>

Suppose a plugin contains a file called LICENSE or README.txt. Which
LICENSE or README.txt wins?

>> 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.
>
> I think you are overanalyzing the problem

I don't think so.  Perhaps Pau can give us his view on the
desirability of a single directory for all plugins artifacts from a
distribution maintainers perspective.

>> 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
>
> I don't see how this will avoid conflicts. what files are you thinking that
> the different plugins will make that won't conflict any more than the
> commands themselves will?

No, but you can manage the conflicts. Hence _managed_ plugins.

   git plugin activate

can fail with a non-zero exit code if there will be a conflict.

>
>> It probably does require a git plugin command of some kind, however,
>> in order to perform the activation step.
>
> only if you think you need a 'installed but not active' mode of operation,
> and I don't understand why you would want that.
>

For the reasons of managed conflict management.

I don't want to drop a new plugin into a common directory only to find
it has blitzed some other plugin I previously did the same with.

Still, I guess it is horses for courses.

jon.