From: Jon Seymour Date: Wed, 27 Apr 2011 22:32:48 GMT Subject: Re: RFC: a plugin architecture for git extensions? Message-ID: In-Reply-To: <20110427220748.GA19578@elie> On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder wrote: > Junio C Hamano wrote: > 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.