Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 9, 2011, 11:07 UTC
Message-ID: <BANLkTikUjGLBH6_ze7EvRfoKb9h-RREmuA@mail.gmail.com>
In-Reply-To: <20110509104446.GB9060@sigill.intra.peff.net>

On Mon, May 9, 2011 at 8:44 PM, Jeff King <peff@peff.net> wrote:

Show 39 quoted lines

> On Mon, May 09, 2011 at 06:45:56PM +1000, Jon Seymour wrote:
>
>> I am starting to think that deploy-via-zip/tar is unworkable for the
>> case where the extension wants to supply html, since I think an
>> attempt has to be made to deploy HTML in the path reported by git
>> --html-path for reasons of HTML  linkability from extension back to
>> the pages from git-core.
>
> Yeah, I don't see a way around that without post-processing the HTML
> links at install time (or creating a symlink farm with all of the HTML
> pages).
>
>> So, suppose we call it --preferred-extension-path*, then if the user
>> (root or otherwise) defines
>>
>>     git config core.preferrred-extension-path ${HOME}/.gitplugins
>>
>> then they get to choose where the installer next run will install extensions.
>
> I thought about suggesting that, but a config option didn't seem a good
> fit to me. The decision of where to put a package seems more likely to
> be related to which _package_ it is, than which user you are. So a
> command-line option would make more sense. And even if you have a config
> option, you would sitll need a command-line one to override, so it's not
> like you are reducing the amount of code or complexity.
>
> Which again makes it not a git issue at all, but an issue for
> package-writers who want to provide a script. It's their job to interact
> with the user and find out where the user wants to put things (i.e.,
> personal or system directories).
>
> 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. 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.

Ideally most extension installs would not require any kind of configuration or decision by the user - simply a statement, I want this installed and I want it to be available immediately.

The idea, I think, is to make this decision once, not every single extension install. Chances are git's default guess will be pretty good (say, /usr/local), but if a user decides that he wants to install this, and all future extensions in ~/.gitplugins, then this can be indicated once, with global configuration that overrides the compiled in default.

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).

jon.