Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 22:32 UTC
Message-ID: <BANLkTikSsoCP_d34wdBHX=r336zJSHSWEQ@mail.gmail.com>
In-Reply-To: <20110427220748.GA19578@elie>

On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

> Junio C Hamano wrote:

Show 5 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?  In this case, I would
> be a little worried.  How will the helper deal with uninstallation and
> with namespace conflicts?  (On the $PATH, these are expected problems
> and I'd expect each user has some way of dealing with them already.)

I see 'git pm activate' managing symbolic links in a directory dedicated to the purpose (.e.g. ~/.git-pm/activated).

One thing 'git pm activate' could do is check that the commands exported by the 'gitwork' descriptor do not conflict with what is already activated.

If the user has done something like:

    git clone https://repo/gitwork.git ~/hub/gitwork

and then:

    git activate pm ~/hub/gitwork

the symbolic links would be established to ~/hub/gitwork, wherever that happens to be.

If the user has done:

   apt-get install gitwork

then given a package-manager adapter for apt-get, it could extract the .gpm file from the list of installed files, and resume activation from there. Ultimately, the end result is the same ~/.git-pm/activated is updated, it has always been on the paths it needs to be.

If the descriptor did have a list of exported commands (e.g. git-work, git-base, git-atomic, git-test), then a global registry could use this list of exported commands to detect conflicts early - at package registration time which might help avoid grief down the track.