Re: RFC: a plugin architecture for git extensions?

From: Pau Garcia i Quiles <pgquiles@elpauer.org>
Date: Apr 28, 2011, 07:40 UTC
Message-ID: <BANLkTi=VLKoKxib+_NDOJYKL-R=AZWDi6g@mail.gmail.com>
In-Reply-To: <BANLkTimnkBMRH7Spj1ByQRa9YdV9w+bwtQ@mail.gmail.com>

On Thu, Apr 28, 2011 at 4:08 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

Show 11 quoted lines

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