threads / announce / 9172

[ANNOUNCE]: PyGit and libgit-thin

Subject: [ANNOUNCE]: PyGit and libgit-thin

## tl;dr

5 messages between Jul 23, 2007 and Jul 25, 2007.

replies: 4people: 4as markdown or json

Luiz Fernando N. Capitulino· Jul 23, 2007, 12:35 UTC · lore

Hi there,

I'm the student working on the gsoc libfication project with Shawn and it has reached the point where I need some feedback in order to decide what to do next.

The project's goal was/is to change what is needed in GIT in order to make it easier to use as library. This is useful for 'external' applications which wants to be able to perform GIT operations w/o having to fork-exec GIT process (and also w/o having to parse git's programs output). Example of such applications are language bindings and IDEs' plugins.

However, the need for this is not a consensus. Some disagree (Linus included I think) and IIRC Junio has stated that he'd probably be against a stable API.

So, in order to make things simple and have a clear separation of what is additional interface not needed by GIT we (Shawn and I) have decided to work on a new library which uses git's low-level interface.

That library is called libgit-thin and currently it's capable of revision listing, commit parsing and some other things.

To demonstrate how to use the library, I've also written a python module which exports to python all the library's functionality.

Now I need to know whether this' really useful to other people and if so, what would be missing for you to start using it.

The project can be found at:

http://repo.or.cz/w/git/libgit-gsoc.git

Look into the 'libgit-thin' directory. Note that it's a fork of Junio's tree, so if you have his repository around do:

$ git clone --reference /path/to/junio/repo git://repo.or.cz/git/libgit-gsoc.git

A demo of the python's module is available here:

http://repo.or.cz/w/git/libgit-gsoc.git?a=blob;f=libgit-thin/pygit/demo.txt;h=f4f9cb726e06ac18a3bf125f3caa7c50dd095361;hb=HEAD

Please, keep in mind that the library's code is still experimental and most of the python module's code is untested.

It's also important to say that there's no much documentation available, you'll have to know a bit about git's implementation for this stuff to be useful for you.

 Thanks a lot for reading this and any kind of feedback is welcome.

-- 
Luiz Fernando N. Capitulino

Yann Dirson· Jul 25, 2007, 19:50 UTC · re: Luiz Fernando N. Capitulino · lore

Re: [ANNOUNCE]: PyGit and libgit-thin

On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:

> Now I need to know whether this' really useful to other people and
> if so, what would be missing for you to start using it.

The python module would really be useful to StGIT. Currently, an stgit commands typically has to fork several git commands at least, and using library calls instead would surely help with the performance.

I had a quick look at the current pygit API (as described in the README), and I find the current revlist one somewhat confusing. Why using post-contructor methods, and not using named args in the constructor itself ?

That is, the example reading:

Show 5 quoted lines

>>> rv = repo.revlist()
>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
>>> rv.count = 10
>>> rv.show_merges()
>>> for commit in rv:

... print commit.id() ...

would be IMHO much nicer to use as:

>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),

... count = 10, ... show_merges = true) ...

>>> for commit in rv:

... print commit.id() ...

What do you think ?

Best regards,

-- 
Yann

David Kastrup· Jul 25, 2007, 19:57 UTC · re: Yann Dirson · lore

Re: [ANNOUNCE]: PyGit and libgit-thin

Yann Dirson <ydirson@altern.org> writes:

Show 28 quoted lines

> I had a quick look at the current pygit API (as described in the
> README), and I find the current revlist one somewhat confusing.  Why
> using post-contructor methods, and not using named args in the
> constructor itself ?
>
> That is, the example reading:
>
>>>> rv = repo.revlist()
>>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
>>>> rv.count = 10
>>>> rv.show_merges()
>>>> for commit in rv:
> ...  print commit.id()
> ... 
>
>
> would be IMHO much nicer to use as:
>
>>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),
> ...                   count = 10,
> ...                   show_merges = true)
> ...
>>>> for commit in rv:
> ...  print commit.id()
> ... 
>
>
> What do you think ?

Nicer to use if the commands and their options originate from withing Python. But if Python parses arguments from somewhere else and passes them on, the former interface leads to much cleaner code AFAICS. Pasting together a named argument call piecemeal is not going to be pretty, I should think.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Jan Hudec· Jul 25, 2007, 21:21 UTC · re: David Kastrup · lore

Re: [ANNOUNCE]: PyGit and libgit-thin

On Wed, Jul 25, 2007 at 21:57:59 +0200, David Kastrup wrote:

Show 5 quoted lines

> Nicer to use if the commands and their options originate from withing
> Python.  But if Python parses arguments from somewhere else and passes
> them on, the former interface leads to much cleaner code AFAICS.
> Pasting together a named argument call piecemeal is not going to be
> pretty, I should think.

You just put all the arguments in a dict and use the ** syntax. And if you already get the arguments in a dict from the parser, it's even nicer.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Luiz Fernando N. Capitulino· Jul 25, 2007, 20:55 UTC · re: Yann Dirson · lore

Re: [ANNOUNCE]: PyGit and libgit-thin

Hi Yann,

On 7/25/07, Yann Dirson <ydirson@altern.org> wrote:

Show 8 quoted lines

> On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:
> > Now I need to know whether this' really useful to other people and
> > if so, what would be missing for you to start using it.
>
> The python module would really be useful to StGIT.  Currently, an
> stgit commands typically has to fork several git commands at least,
> and using library calls instead would surely help with the
> performance.

 Cool.

Show 28 quoted lines

> I had a quick look at the current pygit API (as described in the
> README), and I find the current revlist one somewhat confusing.  Why
> using post-contructor methods, and not using named args in the
> constructor itself ?
>
> That is, the example reading:
>
> >>> rv = repo.revlist()
> >>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')
> >>> rv.count = 10
> >>> rv.show_merges()
> >>> for commit in rv:
> ...  print commit.id()
> ...
>
>
> would be IMHO much nicer to use as:
>
> >>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),
> ...                   count = 10,
> ...                   show_merges = true)
> ...
> >>> for commit in rv:
> ...  print commit.id()
> ...
>
>
> What do you think ?

 I think you're right, that'd be nicer.

 The problem is that the revlist operation accepts a lot of options,
and to change
all (or a big amount of them) would force one to build a very length list of
arguments.

 Currently we have just a few, but we'll add more in the future.

 Also, I think that it won't be that nice to play with include() and exclude(),
since you can call them more than once.

 I'm not sure whether in its current state the module (plus the library) is
useful for stgit.

 Please, feel to make questions and to ask for what'd be missing for you
to adopt it.

 I'm a quilt user and completely forgot that stgit is written in python. I'll
take a look.

 Thanks for your comments,

-- 
Luiz Fernando N. Capitulino