Re: RFC: a plugin architecture for git extensions?

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

On Thu, Apr 28, 2011 at 7:25 PM, Andreas Ericsson <ae@op5.se> wrote:
> On 04/28/2011 04:49 AM, Jon Seymour wrote:
>> On Thu, Apr 28, 2011 at 12:15 PM, Jon Seymour<jon.seymour@gmail.com>  wrote:
>>> Then a command like:
>>>
>>>     git install gitwork
>>>
>>> would trivially work across all distributions precisely because the
>>> distribution has provided the implementation of the git install
>>> interface contract that git-core has helpfully mandated.
>>>
>>
>> Or better yet, git-core could provide a trivial git install
>> implementation that selects between different distribution manager
>> supplied plugins selected according to some heuristic, allowing
>> several distribution managers to happily manage plugins in the same
>> git instance.
>>
>> I have to ask.
>>
>> Is such an architecture really "absolutely horrid"? Is it  "crap"? Really?
>>
>
> Yes, because it forces all distributions to name their extensions
> the same and it forces all distributions to carry the same extensions.

False.

Distributions maintain a N:1 registry of git plugin names to
distribution specific package names. This registry would most
naturally be maintained by the author who maintains the git package,
but of course, such responsibilities could be delegated to others if
required.

During installation, the package manage aware "install" plugin
consults such a registry to determine which packages need to be
installed in order to obtain the requested plugin. It then asks the
package manager to install said packages.

> It also makes it impossible to support 3rd party extensions that core
> git doesn't know about and that aren't already packaged, unless you
> want the "git install" command to have knowledge about all package
> management systems and *very, very good* heuristics when guessing what
> a particular extension is called on that system.
>

Again false. That is the role of the registry that is maintained by
some package author.

> What will happen though is that the distributions will happily ignore
> that and the "git install" command will fail for some extensions on
> some distributions.

Yes, but it can fail in a extremely precise way. In those cases, it
could fall back another package manager
such as one that is capable of checking out a git repo and running make install.

I realise that most people could not accomplish such a task without
writing vast amounts of spaghetti code, but there you go.

>
> Besides that, it forces users to install git from their distribution
> packages so we're hard-shafting the git developers who usually have
> at least some installations done from source.
>

No it doesn't. My suggestion allows deploy by drop-in configuration to
a subdirectory of plugins/ followed by the invocation of a command
such as.

  git plugin activate foobar

I realise this may "hard-shaft" the git developers who are unable to
invoke a git command, but I guess they could also put such a command
in their make install scripts. Now there's an idea.

> We just went far beyond "absolutely horrid" and into the realms of
> "steaming pile of abominably manure-like ideas whose inventor should
> be slapped silly for their own good".
>

Thanks, I'll add that to my vocabulary of terms that git developers
use when they let fly to their emotions for completely unaccountable
reasons. I'd suggest,. perhaps "grow up", but that would strike some
as rude. So, I won't.

> So let's get back to the basic wish you have here. You want people
> to be able to easily find, download and install "git work" so that it
> works nicely with man-pages and all.
>

What is so  hard about:

  app install plugin.

Forget git. Forget git work.

What is so hard about the concept of an application providing a
facility that allows it to request, merely request, the installation
of a plugin for itself by what ever happens to be the users choice of
package manager or distribution.

Is such a concept really, fundamentally flawed?

if so, replace "git" with "linux", "app" with "apt-get", "plugin" with
"git-core" and explain to me why

apt-get install git-core

is such a bad idea.

Yes, different levels of abstraction, but the principles are the same.

Like it or not, git is a platform, there is absolutely no reason why
it can't have sane plugin manager, other than complete lack of
imagination.


> The wiki-page with known extensions and the patch to core git so that
> "make install" can put man-pages in the right directory are the first,
> simplest and smallest steps that takes us the farthest towards that
> wish without burdening people you have no control over with more labor.
> In short; It's both good engineering and polite to implement that and
> then consider what new possibilities open up and see what people do
> with those possibilities. You might be surprised.

Yep, that's what unix package management was like before people
invented the idea of package managers.

How quaint.

jon.