From: Jon Seymour Date: Thu, 28 Apr 2011 00:54:46 GMT Subject: Re: RFC: a plugin architecture for git extensions? Message-ID: In-Reply-To: On Thu, Apr 28, 2011 at 10:50 AM, Jon Seymour wrote: > On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wrote: >> Jonathan Nieder 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. > Sorry, sorry/. git-core stops at #1!! > jon. >