Re: RFC: a plugin architecture for git extensions?

[Pau Garcia i Quiles <pgquiles@elpauer.org>]

Hi,

Can we please split this debate into the two threads that have arisen?

a) git extensions (the original point)

b) git package manager


Let me give my unrequested opinion:

a) I like it. Mercurial has it. It requires more or less what Jon says
below: let's define a hierarchy of where to place the executables,
documentation, the extenions' porcelain (which IMHO would require one
directory per extension), etc

b) Please no. As a Debian developer, I'd rather see extensions
distributed as source, then I would package them. It's what Debian
(and other distributions) are doing now with Ruby gems, Python eggs,
etc: we provide packages for them so that you do not use gem, etc





On Wed, Apr 27, 2011 at 7:33 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> Hide quoted text -
> On Wed, Apr 27, 2011 at 3:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jon Seymour <jon.seymour@gmail.com> writes:
>>
>>>> So if you have /home/js/bin on your $PATH, you can install your "git-work"
>>>> script as /home/js/bin/git-work, and that should be sufficient.
>>>
>>> Yep, that's a start, but does not a a complete plugin architecture make :-)
>>
>> Please explain yourself.
>>
>
> So, I think at a very minimum, a plugin architecture should specify
> the file system layout of packages to be managed by a plugin/package
> manager.
>
> So, where to find scripts, where to find man pages, bash completions,
> configuration help etc.
>
> A slightly more functional architecture would provide support for
> unpacking package archives into a "standard" repository location and
> for removing unwanted plugins.
>
> A plugin architecture might specify a standard way to access
> extensions. (git blah is easy for local use, but what if a plugin
> grabs a "noun" that the core wants to use that "noun" itself in
> future. Perhaps gitx blah would be a better standard way to access
> extensions. But that is an aside, I am sure this question has been
> considered previously).
>
> An even more functional architecture would provide support for a
> global registry of plugins. I understand that git may not want to
> write its own package manager (how many times has that been done),
> but it'd be nice if competing "git package managers" had a standard
> target to deploy to.
>
> My thoughts about this are inspired by how the node project manages
> packages with its npm package manager and also the fact that I have
> several ideas on the boil at the moment that would definitely benefit
> from a standard way to manage these concerns.
>
> jon.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)