Re: RFC: a plugin architecture for git extensions?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 27, 2011, 23:42 UTC
Message-ID: <20110427234224.GA26854@elie>
In-Reply-To: <7vsjt35l84.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 5 quoted lines

> I was thinking it, and the location git-work binary gets installed, should
> depend on where "git" and its subcommand binaries are installed.  The word
> plug-in mentioned in the thread implied that whatever plugs in is not by
> itself full fledged thing that is useful standalone, so it seemed a very
> natural thing to do.

With the goal of making some commands available to git without putting them on the $PATH in mind, this all makes more sense. Sorry I missed that before.

Show 6 quoted lines

>> Or is the idea to blindly install (a symlink to) git-work to $(git
>> --exec-path)/ rather than a place on the $PATH?
>
> You can call it _blindly_ if you like, but that is what I meant.  "git"
> tells where the binary and help material for a "plugin" to be installed,
> so that it can find them where it expects to.

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). A simple way would be to introduce GIT_MAN_PATH as you described and to teach "git help" to accept a GIT_EXEC_PATH consisting of a colon-delimited (semicolon-delimited on Windows) list of directories.