From: Jon Seymour Date: Mon, 09 May 2011 11:28:26 GMT Subject: Re: RFC: a plugin architecture for git extensions? Message-ID: In-Reply-To: <20110509112428.GE9060@sigill.intra.peff.net> On Mon, May 9, 2011 at 9:24 PM, Jeff King wrote: > On Mon, May 09, 2011 at 09:07:31PM +1000, Jon Seymour wrote: > >> > I don't really see any need for git's role in this to be more than: >> > >> >  1. Check a set list of directories for extra paths to add to PATH and >> >     MANPATH. >> > >> >  2. Tell the packager's script what that set list is, so they can be >> >     sure to put their files in the right spot. >> > >> >> The problem with presenting a list of possible directories is that >> given a list, the choice is ambiguous. > > Well, yeah. Though between git and the package script, I think it ends > up being simplified to the --system-extension-dir thing, because out of > the three places I mentioned you might want to install something: > >  1. You definitely don't want to install in the distro location. If you >     did, then you would be a distro package, and therefore would not >     have to be asking git where that location is. > >  2. You do need to know where the locally-installed system path is, so >     we provide an option to query that. > >  3. You don't need to ask git where the per-user path is. It will be at >     some well-known location like $HOME/.gitplugins. > > That being said, I think you are more concerned with not presenting > too many choices to the user. And that still leaves one choice: system > (2) versus user (3) install. > > But I don't think there's a way around that. You are going to have users > of both types, and you will want to serve them. You can make a guess > based on something like writability of the system directory, I suppose, > and let them override via the command-line if they want to. > > That strikes me as somewhat flaky and unpredictable, but I am perhaps > not a representative sample. I have always thought the Windows "if you > install as Administrator, it is available to everybody, but otherwise it > is available only to you" behavior was confusing, and this seems like > the same thing. > >> Sure a decision procedure can be arrived at to choose, but it might be >> hard for the user to predict what decision the procedure will reach. >> In that case, the user must be prompted for a selection. > > I think this is in agreement with what I just wrote above. > >> Again, part of the idea is to give the extension installer some degree >> of confidence that the selected prefix/bin is, in fact, in the path >> and to give the user an override in case the compiled in default isn't >> workable for some reason (for example, due to a permissions issue). > > So from this, I gather you would like to see something like: > >  $ cd git-work && ./install >  fatal: unable to write to /usr/local/share/git: permission denied >  You may install git-work just for the current user with: > >    ./install --user > > I.e., the script has a predictable and sane behavior, but you guide the > user through overriding it if need be. That doesn't seem unreasonable to > me. > > Anyway, with respect to "core.preferredPluginPath", if you do want to go > in that direction, I don't think any extra git support is needed. You > can already just do "git config --path core.preferredPluginPath" to get > the value (with tilde-expansion, even). > > -Peff > I still think it would be useful for the git wrapper to add core.preferredPluginPrefix/bin to the PATH, so that there is no requirement for the user to do this separately via mechanisms that will differ according to platform, shell etc. jon.