Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 9, 2011, 08:45 UTC
Message-ID: <BANLkTimKRo_36Ce2aFWWXdM1a+EgQ-u77Q@mail.gmail.com>
In-Reply-To: <20110509081219.GB6205@sigill.intra.peff.net>

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

Show 34 quoted lines

> On Mon, May 09, 2011 at 05:49:27PM +1000, Jon Seymour wrote:
>
>> Yep, that was part of the motivation for the suggestion - something
>> that works consistently, assuming only a working git installation.
>>
>> Per one of my other notes, my initial inclination is to provide a
>> patch that implements support for
>>
>>      git --system-extensions-dir
>>
>> which would:
>>    - provide the caller with location that extensions could be
>> installed in (assuming the caller can acquire write privileges)
>>    - provide a guarantee that $(git --system-extensions-dir)/bin will
>> be on the path set up by the git wrapper and $(git
>> --system-extensions-dir)/man will be in the MANPATH searched by git
>> help
>>
>> Extensions could then use this information, together with git
>> --html-path to install themselves into these places using whatever
>> mechanism seems appropriate (either a POSIX shell script or a
>> make/install script).
>
> But is the system extension dir always the right place to do so? If I'm
> not root, then that probably won't be writable (or even if I am, I may
> want to install the extension only for the root user).
>
> If your proposal is for the user to decide on one of:
>
>  unzip -d "$(git --system-extension-dir)" git-foo.zip
>
> or
>
>  unzip -d "$HOME/.gitplugins" git-foo.zip

Show 5 quoted lines

>
> then they can make that decision. But if you're proposing that the
> extension-writer distribute a script, then it's more complicated. They
> would probably need to provide a "--user" versus "--system" option.
>

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.

Now, this might not always work, and the install script can either fail (to be re-run under sudo at users discretion) or degrade gracefully (install what it can, and warn).

Show 21 quoted lines

> It would also be tempting to write something like:
>
>  install_dir() {
>    if test "`id -u`" = "0"; then
>      git --system-extension-dir
>    else
>      echo $HOME/.gitplugins
>    fi
>  }
>
> but that is:
>
>  1. Not portable.
>
>  2. Does not allow for user-only installation by root.
>
> But all of this is a packaging best-practices issue, not an issue of
> what git needs to do to support it (you _could_ address the portability
> issue by having "git --preferred-extension-path" that did the
> appropriate platform-specific UID check, but that still doesn't address
> the second point).

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.

Also, this would only be a default - installation scripts could have a mechanism to specify an override on the command line. Of course, if they supply the override and it is not consistent with --preferred-extensions-path/core.preferred-extensions-path then they need to take steps to install that the bin directory is in the PATH, but that's a decision they take themselves as an alternative to acquiring the privileges required to modify the directory reported by git --preferred-extensions-path

The idea is for core to provide extension installers with just enough information that their installs will work and be discoverable by the core and enough control for distributions to determine the preferred location for such extensions.

* I would prefer --preferred-extension-dir rather than
--preferred-extension-path, since I think this name should specify a
single directory and not a list (otherwise the choice of destination
would be ambigiuous). I realise this creates an inconsistency with
--html-path and if consistency is preferred (or I have misinterpreted
what path normally means), I am happy to use
--preferred-extension-path.

jon.