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

[Jeff King <peff@peff.net>]

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