Re: RFC: a plugin architecture for git extensions?
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Apr 27, 2011, 22:47 UTC
- Message-ID
- <BANLkTinxFNSXEnRR0ZACO0W-+kDL0CD-qg@mail.gmail.com>
- In-Reply-To
- <BANLkTimsWmtXzogjN4bPkhmV8K=y1c4AmA@mail.gmail.com>
On Thu, Apr 28, 2011 at 8:32 AM, Pau Garcia i Quiles <pgquiles@elpauer.org> wrote:
Show 16 quoted lines
> 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 >
Show 5 quoted lines
> 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 >
I absolutely agree that is the right approach. To the extent that my proposal supports:
git pm install foobar
it would do so by delegation to package-manager adapters (in effect acting as a meta package manager).
However, I don't want to further distract discussion by having a debate about whether a meta package manager is a good idea or not. So let's concentrate on what:
git pm activate
would look like and do.
jon.