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

[Justin Clift]

Hi Thiago,

How's this stuff going?  Is it ready enough for real world usage?

eg should we think about ripping the existing Python libgfapi code
out of main Gluster 3.5 dev tree, and using this instead? :)

Regards and best wishes,

Justin Clift


On 29/10/2013, at 1:34 PM, Luis Pabon wrote:
> 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
> 

--
Open Source and Standards @ Red Hat

twitter.com/realjustinclift