[ANNOUNCE]: PyGit and libgit-thin

[ANNOUNCE]: PyGit and libgit-thin

[Luiz Fernando N. Capitulino]

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

Re: [ANNOUNCE]: PyGit and libgit-thin

[Yann Dirson]

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:

>>> 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

Re: [ANNOUNCE]: PyGit and libgit-thin

[David Kastrup]

Yann Dirson <ydirson@altern.org> writes:

> 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

Re: [ANNOUNCE]: PyGit and libgit-thin

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Wed, Jul 25, 2007 at 21:57:59 +0200, David Kastrup wrote:
> 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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE]: PyGit and libgit-thin

[Luiz Fernando N. Capitulino]

Hi Yann,

On 7/25/07, Yann Dirson <ydirson@altern.org> wrote:
> 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.

> 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