Re: RFC: a plugin architecture for git extensions?

From: david@lang.hm <david@lang.hm>
Date: Apr 28, 2011, 00:55 UTC
Message-ID: <alpine.DEB.2.00.1104271751300.940@asgard.lang.hm>
In-Reply-To: <BANLkTi=w0aKH6dxu84i4DjkL-vNCWQi8pw@mail.gmail.com>

On Thu, 28 Apr 2011, Jon Seymour wrote:

Show 21 quoted lines

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

Show 5 quoted lines

> 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

Show 9 quoted lines

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

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

David Lang

Show 15 quoted lines

> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>