Re: RFC: a plugin architecture for git extensions?

[Jon Seymour <jon.seymour@gmail.com>]

On Mon, May 9, 2011 at 9:24 PM, Jeff King <peff@peff.net> 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.