Re: RFC: a plugin architecture for git extensions?
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- May 8, 2011, 13:13 UTC
- Message-ID
- <BANLkTinhN0=2NETtOjG_yvubHiZagGB0Wg@mail.gmail.com>
- In-Reply-To
- <20110506065601.GB13351@elie>
On Fri, May 6, 2011 at 4:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 6 quoted lines
> > But now I am less sure. The motivating example has less than 10 > commands; that doesn't seem worth all the fuss at all. Why not just > install the command on the $PATH? "git help work" _would_ work on all > the systems I have easy access to. For example, if I write: >
An aspect of the motivational example that I would welcome your feedback on is this.
git-work is an example of an extension that depends on 3 other extensions (git-base, git-atomic and git-test).
Similarly:
git-base depends on git-test. git-atomic depends on git-test
It seems that if I am to represent these dependencies, I need to create 4 * N packages, where N is the number of packaging systems I want to support.
It is unclear how I make:
make install prefix=/usr/local
work unless the 3 other dependencies have been installed first. If I need to explain that these 3 other dependencies need to be installed, then my installation instructions have just become longer.
This seems a shame, since each extension has a dependency only on other git extensions and git itself. Yet, to provide a workable installation from source option for my users, I need to either get them to fetch and build all 4 packages from source, or I need to build packages for N different distribution managers.
[ FWIW: I recognise that my current proposals for a simple git --system-extensions-dir don't make this problem any easier to solve, but I wanted to use the example to demonstrate why a simple make install script isn't the silver bullet to every installation scenario ].
jon.