Re: RFC: a plugin architecture for git extensions?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 07, 2011 at 12:07:14AM +1000, Jon Seymour wrote:

> I think the problem we are trying to solve is this: how to make it as
> easy as possible to install, and get operational, an extension to git.
> 
> If git supported the concept of a standard place to put extensions,
> then it could be as simple as:
> 
>     unzip -d $(git --plugins-dir) plugin.zip
> 
> with no need to configure or choose a prefix and no need to edit the
> an .profile or .bashrc to permanently add a directory to the PATH.

This seems slightly backwards to me. You are asking git "where should
plugins go?" and then putting them there. But that leaves no room for
plugins going in _multiple_ places. IOW, the usual hierarchy of:

  1. distribution-packaged extensions (in /usr/share/git/plugins)

  2. local system-wide extensions (in /usr/local/share/git/plugins)

  3. per-user extensions (in $HOME/.gitplugins)

It seems like we should not be asking git, but _telling_ git about where
our plugins are. I understand that you don't want the user to have to do
any additional steps, and I think that is a reasonable goal. But can't
that be easily accomplished by:

  1. The git wrapper learns to look in a set of plugin paths, something
     like:

       foreach path in (list of plugin paths)
         foreach plugin in "path/*"
           add plugin/bin to PATH
           add plugin/man to MANPATH

  2. At compile time, we give some stock system directories like
     /usr/share/git/plugins and /usr/local/share/git/plugins.
     Distribution packages of git override as appropriate for the target
     system.

  3. We always check $HOME/.gitplugins by default.

  4. Users can set GIT_PLUGIN_PATH in the environment if they want to do
     something fancy (they can also always just set PATH and MANPATH
     manually if they want, too).

This is how many systems already work. For example, look at how vim
handles plugins.

Distro-packaged extensions obviously know where to go (the packager
knows their distro's rules). People with personal extensions don't have
to know anything special; their packages go in $HOME/.gitplugins.

In general I would expect /usr/local/share/git/plugins to be pretty
standard, and not needing of being repeated for admins who want to
install something system-wide. But if you want to be really thorough,
then your "git --plugins-dir" should probably report the "system-wide
but not distro" directory for that (but I would call it something like
"git --system-plugins-dir" or something to make it more clear).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]