Re: RFC: a plugin architecture for git extensions?

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

On Thu, Apr 28, 2011 at 5:40 PM, Pau Garcia i Quiles
<pgquiles@elpauer.org> wrote:
> On Thu, Apr 28, 2011 at 4:08 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
>
>>>> I guess an unmanaged solution could use separate directories for each
>>>> plugin, but this would imply scanning all these paths each time you
>>>> invoke git. In my view, symbolic links from a dir already
>>>> GIT_EXEC_PATH to plugin directories would be a more efficient way to
>>>> do this.
>>>
>>> I think you are overanalyzing the problem
>>
>> I don't think so.  Perhaps Pau can give us his view on the
>> desirability of a single directory for all plugins artifacts from a
>> distribution maintainers perspective.
>
> You are thinking too much, this is simpler than what you are trying to do :-)
>
> What packages in Linux distributions do is essentially placing files
> where the FHS says, i. e:
>
> - Binaries intended to be used by an average Joe go to /usr/bin
> - Binaries for internal consumption go to /usr/lib/packagename
> - Libraries go to /usr/lib
> - Documentation goes to /usr/share/doc/packagename
> - Manual pages to go /usr/share/man/manX/command.X.gz
> - etc
>
> Define something like that inside the prefix where git is installed
> and you are done. As Junio said, git already checks for git-* presence
> for help, etc.
>
> If you want to see more about package organization, go to
> http://www.debian.org/Packages/unstable/ , go to that package's page
> and at the bottom there is a "List of files" link. For instance
>
> http://packages.debian.org/experimental/git
> http://packages.debian.org/experimental/amd64/git/filelist
>
> BTW, I fail to see why an "activation" step is needed. Either it is
> installed or it is not.
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>

Ok, I have tried to explain why separating the concerns of package
management and plugin management is an appropriate thing to do, and
why one directory for each plugin is also a good thing to do. BTW: I
thought you actually suggested this concept yourself in your earlier
post.

I also explained why an activation step is desirable. It is good for
performance (since you don't have to resolve across plugin directories
on each invocation) and it is good for conflict management (since you
get a precise means to identify and prevent conflicts). More over, the
application which provides the plugin manager gets to do this conflict
detection and prevention, which is exactly the right component to do
it. Why? because it understands its own plugin architecture better
than any and all plugin authors, package authors or package managers.

There is probably only so many times I can explain these principles.

As they saying goes - code talks. I'll implement things as I think
they should be implemented, incorporating the constructive suggestions
that have been made.

To be sure, even the insults have helped.

Calling the idea of:

    git install foobar

"horrid" and then "utterly horrid" and then "crap" has just helped
crystalise in my mind exactly where the correct lines of
responsibility should be drawn between, application, plugin and
package.

It appears that many people still don't get it but there is only so
much I can do about that.

Anyway, thanks for all your help (constructive and otherwise),

jon.