Re: Python extension commands in git - request for policy change

From: Jeff King <peff@peff.net>
Date: Dec 12, 2012, 06:32 UTC
Message-ID: <20121212063208.GA18322@sigill.intra.peff.net>
In-Reply-To: <20121212033043.GA24937@thyrsus.com>

On Tue, Dec 11, 2012 at 10:30:43PM -0500, Eric S. Raymond wrote:

> My sense is that git's use cases are better served by a glue language
> in the Python/Perl/Ruby class rather than an extension langage. But
> my mind is open on this issue.

I think there are really two separate use cases to consider:

  1. Providing snippets of script to Git to get Turing-complete behavior
     for existing Git features. For example, selecting commits during a
     traversal (e.g., a better "log --grep"), formatting output (e.g., a
     better "log --format" or "for-each-ref --format").

  2. Writing whole new git commands in a language that is quicker or
     easier to develop in than C.

I think (1) is a good match for lua. It's light-weight and easy to embed, we can map the few bits of information we want for each snippet into the language (e.g., a commit object as a lua table), and the language ecosystem is not that important (the user is more interested in writing readable one-liners manipulating data provided by git than they are in calling out to third-party modules).

But for (2), you are going to care a lot more about the language and its ecosystem (because you'll be interacting more with the world outside of git), and about having bindings to lots of different parts of git (because you'll want to do more interesting things than just examine a few data structures). We provide that right now with executable plumbing commands. That's convenient for shell scripts, and you can build bindings for other languages on top (e.g., see perl/Git.pm).

It's nicely universal, but of course there are some drawbacks: it's slow (fork and pipe overhead), and it's sometimes awkward (parsing, quoting, no interactivity between caller and plumbing). The other obvious choice for a lingua franca is a linkable C library, with bindings in your language of choice.

It would take a lot of effort to expose git-core's internals in a clean way; you'd probably be better off starting from scratch and rewriting large parts in a friendly library-like manner. Fortunately, there is already a project underway to do so: libgit2. It does not yet have feature parity with git, but it can do quite a bit. And there are already ruby and python bindings.

-Peff