[Gluster-devel] Glupy bugs: found the solution?

[Luis Pabon]

Hi guys,
     On the python bindings side, we have hired a new developer to spend 
his time divided between gluster-swift and the python bindings for gfapi 
(and probably Java binding on some future date).  His name is Thiago da 
Silva and he started a few weeks ago.
     The gluster-swift project will require, in the near future, to move 
from using FUSE to libgfapi, and so we really need to the python 
bindings to become a real project:  python exceptions, unit tests, 
functional tests, documentation, releases, etc.
     We are also planning on moving the bindings away from the glusterfs 
repo to a new repo.  We have been really busy working on SWAuth for 
Gluster-swift, but we plan on using the same development workflow as 
gluster-swift in python-libgfapi repo.

     Here is the repo information:
Public Repo: https://github.com/gluster/libgfapi-python (for some reason 
it is not syncing with Gerrit.  I'll ping Avati)
Gerrit:  http://review.gluster.org/libgfapi-python

- Luis

On 10/28/2013 03:28 PM, Justin Clift wrote:
> On 27/10/2013, at 8:37 AM, Niels de Vos wrote:
> <snip>
>>> Yeah, that's why I was thinking it was libgfapi stuff getting pulled in
>>> not Swift.  The import line in your pdf needs updating btw, as the
>>> import line for current git head needs to be:
>>>
>>>   from gluster import gfapi
>> Ah, right. I'm not sure I'll update that because at the time of the
>> presentation one needed to use the git repository. During the Gluster
>> Community Day in Stockholm someone (sorry, can't remember the name)
>> asked if gfapi.py could not be included in the packages. Good question,
>> and it showed I wasn't the only one who would benefit from that ;-)
> Kind of thinking this through further, gfapi.py is kind of serving two
> roles at the moment (import + demo).
>
> Should we improve that by moving the import code into a "more proper"
> gfapi.py under api/src/, keeping the Python demo code in the examples
> ("gfapi-demo.py" or similar?)
>
>
>>> <snip>
>>>> the Python package 'gluster' will be the base for other modules. Hence
>>>> we have created put the api bindings in gluster/gfapi.py. I think it
>>>> would make sense to rename the Glupy module gluster.glupy. If it can be
>>>> placed in /usr/lib/python2.6/site-packages/gluster/glupy.py things would
>>>> be even nicer :)
>>> That would make the import line:
>>>
>>>   from gluster import glupy
>>>
>>> Wouldn't it?  No objections to that, it's fairly simple and pretty logical. :)
>> Yes, that's my suggestion. I am not maintaining or developing Glupy, so
>> it is not my call and I have no insight if this would make things more
>> complex somewhere else. I'm still planning to have a look at Glupy, but
>> I have not found the time to do so yet...
>
> Sure, np.  Jeff was wanting to hand the code off to someone else, either
> myself or Ram as we both put time into it.  Not sure if Ram "officially"
> picked it up or not. ;)
>
> I'd be happy to, but there is some technical challenge there... I don't
> understand Python Ctypes at all, and it's not absorbing into me head
> (have tried). :(
>
> + Justin
>
> --
> Open Source and Standards @ Red Hat
>
> twitter.com/realjustinclift
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20131029/6709c9de/attachment-0001.html>